SDR++ Server crashes with seg fault when float32 and sample rate above 13 mhz

[KubaPro010]

FIRST: Before reporting any bug, make sure that the bug you are reporting has not been reported before. Also, try to use the nightly version if possible in case I've already fixed the bug.

Hardware

• CPU: (server: AMD Embedded G-Series GX-420GI Radeon R7E, client: Intel Xeon L5640)
• RAM: (server: 4GB, client: 24GB)
• GPU: (server: integrated, client: gtx 1070)
• SDR: MiriSDR with cropinghigh's source, Remote SDR++ Server
  Software
• Operating System: (server: Debian Bookworm, client: Windows 10)
• SDR++: (server: modified v1.1.0, but any logic touching the faulty thing was not changed, client: v1.1.0 Feb 8 24 20:58:19)

Bug Description
If the sample rate of the SDR is 13 mhz or higher, the Float32 mode crashes the SDR++ server with a seg fault, my best guess, too low ram?

Steps To Reproduce

1. Set Sample Type to Float32
2. Set sample rate to 13 mhz or higher
3. start the receiver

Additional info
Server console logs:

[09/02/2024 20:47:36.000] [INFO] SDR++ v1.1.1 (Server-Edit)
[09/02/2024 20:47:36.000] [INFO] Loading config
[09/02/2024 20:47:36.000] [INFO] =====| SERVER MODE |=====
[09/02/2024 20:47:36.000] [INFO] Loading /usr/lib/sdrpp/plugins/mirisdr_source.so
[09/02/2024 20:47:36.000] [INFO] Running post-init for MiriSDR
[09/02/2024 20:47:36.000] [INFO] MirisdrSourceModule 'MiriSDR': Menu Select!
[09/02/2024 20:47:36.000] [INFO] Ready, listening on 0.0.0.0:5259
[09/02/2024 20:47:38.000] [INFO] Connection from TODO:TODO
[09/02/2024 20:47:41.000] [INFO] MirisdrSourceModule 'MiriSDR': Tune: 95338893!
[09/02/2024 20:47:42.000] [INFO] MirisdrSourceModule 'MiriSDR': Start!
258552 samples lost, 16384, 000001fa:0003f3f2
[09/02/2024 20:47:42.000] [INFO] MirisdrSourceModule 'MiriSDR': Tune: 95338893!
[09/02/2024 20:47:44.000] [INFO] MirisdrSourceModule 'MiriSDR': Stop!
[09/02/2024 20:47:47.000] [INFO] MirisdrSourceModule 'MiriSDR': Tune: 95338893!
[09/02/2024 20:47:47.000] [INFO] MirisdrSourceModule 'MiriSDR': Start!
10370160 samples lost, 16384, 000001fa:009e3e6a
[09/02/2024 20:47:47.000] [INFO] MirisdrSourceModule 'MiriSDR': Tune: 95338893!
[09/02/2024 20:47:49.000] [INFO] MirisdrSourceModule 'MiriSDR': Stop!
[09/02/2024 20:47:52.000] [INFO] MirisdrSourceModule 'MiriSDR': Tune: 95338893!
[09/02/2024 20:47:52.000] [INFO] MirisdrSourceModule 'MiriSDR': Start!
11068974 samples lost, 16384, 000001fa:00a8e828
[09/02/2024 20:47:52.000] [INFO] MirisdrSourceModule 'MiriSDR': Tune: 95338893!
[09/02/2024 20:47:55.000] [INFO] MirisdrSourceModule 'MiriSDR': Stop!
[09/02/2024 20:47:58.000] [INFO] MirisdrSourceModule 'MiriSDR': Tune: 95338893!
[09/02/2024 20:47:58.000] [INFO] MirisdrSourceModule 'MiriSDR': Start!
19184820 samples lost, 16384, 000001fa:0124beae
[09/02/2024 20:47:58.000] [INFO] MirisdrSourceModule 'MiriSDR': Tune: 95338893!
Segmentation fault

[AlexandreRouma]

Known issue, I'll close when it's fixed

[KubaPro010]

for now i'm gonna make a temporary fix doing this:

else if (cmd == COMMAND_SET_SAMPLE_TYPE && len == 1) {
            dsp::compression::PCMType type = (dsp::compression::PCMType)*(uint8_t*)data;
            // if(type == dsp::compression::PCM_TYPE_F32) type = dsp::compression::PCM_TYPE_I16;
            if(type == dsp::compression::PCM_TYPE_F32) {
                if(sampleRate >= 13000000.0) {
                    flog::warn("Prevented Memory Crash");
                    type = dsp::compression::PCM_TYPE_I16;
                } else {
                    flog::warn("Float32");
                }
            }
            comp.setPCMType(type);
        }

guess its better than the server crashing

[AlexandreRouma]

the fix just involves setting the size of the uint8_t stream appropriately in the compression and decompression blocks

[AlexandreRouma]

Fixed