Mystery segmentation fault: Raspberry Pi 5

[connervieira]

I'm running the latest version of Trunk Recorder as of the time of writing, installed via the documentation at https://trunkrecorder.com/docs/Install/INSTALL-PI

I'm using a Raspberry Pi 5 (6.6.74+rpt-rpi-2712) with two RTL-SDR v4.

I'm using a known-good configuration file from a previous installation (which worked reliably for weeks at a time). Here's the configuration contents:

{
    "ver": 2,
    "sources": [{
        "center": 855059375,
        "rate": 2400000,
        "error": 2000,
        "gain": 50,
        "debugRecorders": 0,
        "digitalRecorders": 4,
        "driver": "osmosdr",
        "device": "rtl=0"
    }, { 
        "center": 861350000,
        "rate": 2400000,
        "error": 2000,
        "gain": 50,
        "debugRecorders": 0,
        "digitalRecorders": 4,
        "driver": "osmosdr",
        "device": "rtl=1"
    }],
    "systems": [{
        "control_channels": [855212500, 856037500, 860787500, 860912500],
        "type": "p25",
        "shortName": "OhioMARCS",
        "talkgroupsFile": "./talkgroup.csv",
        "modulation": "qpsk"
    }]
}

trunk-record starts just fine, and begins scanning the configured frequencies, but it will abruptly seg-fault anywhere from 10 seconds to a couple minutes after starting. Here's an example of the console output during such a scenario:

[2025-01-31 23:28:47.020475] (info)   	 - System Source 0 - Min Freq: 853.909375 MHz Max Freq: 856.209375 MHz
[2025-01-31 23:28:47.406096] (info)   	 Xlating Channelizer decimator - freq_xlating taps: 91 Decim: 4 Resampled Rate: 24000 Lowpass Taps: 83
fix_cc :warning: Block (fix_cc0) max output buffer set to 10240 instead of requested 8192
fix_cc :warning: Block (fix_cc1) max output buffer set to 8192 instead of requested 10240
Allocating 15 zero-copy buffers
Allocating 15 zero-copy buffers
[2025-01-31 23:28:47.485722] (error)   [OhioMARCS]	 Control Channel Message Decode Rate: 0/sec, count:  1
[2025-01-31 23:28:50.020621] (error)   [OhioMARCS] Retuning to Control Channel: 856.037500 MHz
[2025-01-31 23:28:50.020728] (info)   	 - System Source 0 - Min Freq: 853.909375 MHz Max Freq: 856.209375 MHz
[2025-01-31 23:28:50.020838] (error)   [OhioMARCS]	 Control Channel Message Decode Rate: 0/sec, count:  1
[2025-01-31 23:28:53.018477] (error)   [OhioMARCS] Retuning to Control Channel: 860.787500 MHz
[2025-01-31 23:28:53.018606] (info)   	 - System Source 1 - Min Freq: 860.200000 MHz Max Freq: 862.500000 MHz
[2025-01-31 23:28:53.421444] (info)   	 Xlating Channelizer decimator - freq_xlating taps: 91 Decim: 4 Resampled Rate: 24000 Lowpass Taps: 83
fix_cc :warning: Block (fix_cc0) max output buffer set to 8192 instead of requested 10240
fix_cc :warning: Block (fix_cc1) max output buffer set to 10240 instead of requested 8192
Allocating 15 zero-copy buffers
Allocating 15 zero-copy buffers
[2025-01-31 23:28:53.505357] (error)   [OhioMARCS]	 Control Channel Message Decode Rate: 0/sec, count:  1
[2025-01-31 23:28:56.020145] (error)   [OhioMARCS] Retuning to Control Channel: 860.912500 MHz
[2025-01-31 23:28:56.020241] (info)   	 - System Source 1 - Min Freq: 860.200000 MHz Max Freq: 862.500000 MHz
[2025-01-31 23:28:56.020298] (error)   [OhioMARCS]	 Control Channel Message Decode Rate: 0/sec, count:  1
[2025-01-31 23:28:59.017980] (error)   [OhioMARCS] Retuning to Control Channel: 855.212500 MHz
[2025-01-31 23:28:59.018096] (info)   	 - System Source 0 - Min Freq: 853.909375 MHz Max Freq: 856.209375 MHz
[2025-01-31 23:28:59.029961] (info)   	 Xlating Channelizer decimator - freq_xlating taps: 91 Decim: 4 Resampled Rate: 24000 Lowpass Taps: 83
fix_cc :warning: Block (fix_cc0) max output buffer set to 10240 instead of requested 8192
fix_cc :warning: Block (fix_cc1) max output buffer set to 8192 instead of requested 10240
Segmentation fault

I followed the steps at https://trunkrecorder.com/docs/DEBUG in hopes of diagnosing the issue. Here's the output of gdb trunk-recorder core:

Reading symbols from trunk-recorder...

warning: Can't open file /SYSV00000000 (deleted) during file-backed mapping note processing

warning: Can't open file /dev/bus/usb/001/004 during file-backed mapping note processing

warning: exec file is newer than core file.
[New LWP 1975]
[New LWP 1840]
[New LWP 1843]
[New LWP 1842]
[New LWP 1841]
[New LWP 1846]
[New LWP 1845]
[New LWP 1860]
[New LWP 1849]
[New LWP 1844]
[New LWP 1848]
[New LWP 1847]
[New LWP 1977]
[New LWP 1857]
[New LWP 1858]
[New LWP 1850]
Core was generated by `trunk-recorder --config=./config.json'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007ffeec702e4c in ?? ()
[Current thread is 1 (LWP 1975)]
(gdb) exit

I've tried re-compiling as well as several restarts. The OS is a clean install, and the only changes are those explained in the documentation. Any idea on what my next steps should be?

[makegofast]

I saw a conversation in discord from 2 months ago that was similar to what you're reporting. The v4 drivers that came with raspbian might be out of date and don't work with v4 but did with v3.

The comment was: "It's because of the v4-compatible drivers, and where they are sourced from. I don't think they're normally available in any raspi distros as of yet, but SDR Trunk essentially has them built-in."

Might be worth checking you have the latest drivers that support the v4?

[Dewey3]

I have been running TrunkRecorder on three RPi5's since July 2024. I've had one instance of seg fault on one of the Pi's during that entire time. Sorry that I don't have an answer, but I do have a shot in the dark that worked for me. Like your first recorder, I had one of my RTL-SDRs (Nooelec NESDR-SMArt) set to a "long" center frequency for a system where the system frequencies were 4 decimal places at the most. I rounded the center frequencies down to a single decimal place (853500000 - [853.500000]) and have not seen that problem since. One of my RPi5's is on system that uses 5 decimal places, so all of the center frequencies for that system are set to 5 decimal places as well. Again, this was just a shot in the dark that worked for me, but I have not seen the problem since, and that was back before Thanksgiving.

[connervieira]

Might be worth checking you have the latest drivers that support the v4?

I did try manually installing the latest drivers according to the RTL-SDR guide, but that seemed to cause some other dependency issues. I figured it was worth trying to solve the issue with the default recommended packages to better identify the issue. Perhaps I'll try that again if I can't resolve it some other way.

I rounded the center frequencies down to a single decimal place

I'll definitely give that a try as well. If I had to guess, there might be something a little more in-depth happening, since it seems to seg-fault within a few seconds of booting up most of the time.

I figured it also might be worth trying to disconnect the antennas to see if the error occurs when a particular transmission is being processed, or if it just happens due to some background process.