Immediate crash on Pi4 -- free error.

[alfille]

After compiling from source on my pi4 I get:

pi@pi4sdr:~/SigDigger $ /opt/SigDigger/bin/SigDigger double free or corruption (out) Aborted pi@pi4sdr:~/SigDigger $ /opt/SigDigger/bin/SigDigger free(): invalid pointer Aborted pi@pi4sdr:~/SigDigger $ /opt/SigDigger/bin/SigDigger Segmentation fault

Each time the splashcreen briefly appears.

What's curious is that it's a slightly different message each time.

[BatchDrake]

Interesting. I never built SigDigger in ARM before and definitely didn't expect it to work. Could you run SigDigger from gdb so I could know where it is failing exactly? Something like:

$ gdb /opt/SigDigger/bin/SigDigger
... Lots of versioning messages ...
(gdb) run

After the crash, gdb will take you back to the (gdb) prompt from which you can run bt and see the full stack trace that caused the crash.

[alfille]

Compilation on pi4 was effortless, by the way.

Here is the results:

`(gdb) run Starting program: /opt/SigDigger/bin/SigDigger [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1". [New Thread 0xb24bd030 (LWP 22303)] [New Thread 0xacf81030 (LWP 22304)] [New Thread 0xac499030 (LWP 22305)] [New Thread 0xab92f030 (LWP 22306)] [New Thread 0xa909b030 (LWP 22307)] [New Thread 0xa889a030 (LWP 22308)] [Thread 0xa909b030 (LWP 22307) exited] [New Thread 0xa7eff030 (LWP 22309)] [New Thread 0xa76fe030 (LWP 22310)] [New Thread 0xa6efd030 (LWP 22311)] [Thread 0xa6efd030 (LWP 22311) exited] [New Thread 0xa62ff030 (LWP 22312)] [New Thread 0xa5afe030 (LWP 22313)] [Thread 0xa5afe030 (LWP 22313) exited] [New Thread 0xa52fd030 (LWP 22314)] [New Thread 0xa4afc030 (LWP 22315)] [New Thread 0xa42fb030 (LWP 22316)] [New Thread 0xa909b030 (LWP 22317)] [New Thread 0xa3afa030 (LWP 22318)] [New Thread 0xa32f9030 (LWP 22319)] [New Thread 0xa2af8030 (LWP 22320)] [Thread 0xa3afa030 (LWP 22318) exited] [New Thread 0xa22f7030 (LWP 22321)] [Thread 0xa889a030 (LWP 22308) exited] [New Thread 0xa889a030 (LWP 22322)] [Thread 0xa42fb030 (LWP 22316) exited] [Thread 0xa4afc030 (LWP 22315) exited] [Thread 0xa7eff030 (LWP 22309) exited] [Thread 0xa62ff030 (LWP 22312) exited] [Thread 0xa32f9030 (LWP 22319) exited] [Thread 0xa52fd030 (LWP 22314) exited] free(): invalid pointer

Thread 5 "SigDigger::Init" received signal SIGABRT, Aborted. [Switching to Thread 0xab92f030 (LWP 22306)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0xb56c6230 in __GI_abort () at abort.c:79 #2 0xb571651c in __libc_message (action=action@entry=do_abort, fmt=) at ../sysdeps/posix/libc_fatal.c:181 #3 0xb571d044 in malloc_printerr (str=) at malloc.c:5341 #4 0xb571ed50 in _int_free (av=0xb57f97d4 <main_arena>, p=0x60e110, have_lock=) at malloc.c:4165 #5 0x000abc24 in std::vector<std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::allocator<std::__cxx11::basic_string<char, std::char_traits, std::allocator > > >::~vector() () #6 0xb6ba614c in SoapySDRDevice_listGains () from /usr/local/lib/libSoapySDR.so.0.8 #7 0xb6f00c00 in suscan_source_device_populate_info (dev=0xab00fd60) at /home/pi/suscan/analyzer/source.c:312 #8 0xb6f01d10 in suscan_source_detect_devices () at /home/pi/suscan/analyzer/source.c:654 #9 0xb6f08734 in suscan_init_sources () at /home/pi/suscan/analyzer/source.c:2458 #10 0x000a43ec in ?? () #11 0x000357ac in ?? () #12 0xb5af3b58 in ?? () from /usr/lib/arm-linux-gnueabihf/libQt5Core.so.5 #13 0xb5a12494 in start_thread (arg=0xab92f030) at pthread_create.c:486 #14 0xb5786578 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) `

[BatchDrake]

The crash is happening inside SoapySDRDevice_listGains so, in a first glimpse, it looks like a SoapySDR issue. However, memory corruption may be happening somewhere before that and I'd like to discard that. If you have valgrind run:

$ valgrind --leak-check=full --track-origins=yes /opt/SigDigDigger/bin/SigDigger 2> crash.log

And attach the resulting crash.log to this issue. Valgrind is going to emulate the code of SigDigger and therefore is going to be slow. I, for my part, am going to attempt to build SigDigger in a Raspberry Pi 3 I have around hoping the crash is reproducible there too.

[alfille]

It is a slow process. My remote session eventually crash.log timed out but here is the log:

[BatchDrake]

I am afraid valgrind didn't even get to the crash, or the log is truncated. Anyways, I will try to repeat this on a Raspberry Pi 3 and I'll tell you if I find anything.

[alfille]

Let me try again on a local console to prevent timeouts.

[alfille]

After 20 hours I get this:

crash.log

[alfille]

I tried chasing down the error and git as far as

InitThread::run() { Suscan::Singleton *sing = Suscan::Singleton::get_instance(); printf("INIT_THREAD\n"); try { emit change("Loading signal sources"); sing->init_sources();

So init_sources -- but I'm not sure if that is in suscan directory (Library.cpp) or the suscan library compiled separately.

For reference, since you thought it might be SoapySDR:

pi@pi4sdr:~ $ SoapySDRUtil --find ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Found device 0 default_input = True default_output = True device_id = 0 driver = audio label = PulseAudio

Found device 1 addr = 1d50:6108 driver = remote label = LimeSDR-USB [USB 3.0] 9061C02C72A3A media = USB 3.0 module = FX3 name = LimeSDR-USB remote = tcp://[fd50:31c1:9aa::e3a%2]:55132 remote:driver = lime serial = 0009061C02C72A3A

And: pi@pi4sdr:~ $ SoapySDRUtil --info ######################################################

Soapy SDR -- the SDR abstraction library

######################################################

Lib Version: v0.8.0-gf722f9ce API Version: v0.8.0 ABI Version: v0.8 Install root: /usr/local Search path: /usr/local/lib/SoapySDR/modules0.8 Module found: /usr/local/lib/SoapySDR/modules0.8/libHackRFSupport.so (0.3.3-3c514ce) Module found: /usr/local/lib/SoapySDR/modules0.8/libLMS7Support.so (20.01.0-4d715e9b) Module found: /usr/local/lib/SoapySDR/modules0.8/libMultiSDRSupport.so (8cdde56) Module found: /usr/local/lib/SoapySDR/modules0.8/libaudioSupport.so (0.1.1-2ae84e3) Module found: /usr/local/lib/SoapySDR/modules0.8/libnetSDRSupport.so (0.1.0-11f80b3) Module found: /usr/local/lib/SoapySDR/modules0.8/libremoteSupport.so (0.5.2-6d9bd82) Module found: /usr/local/lib/SoapySDR/modules0.8/librtlsdrSupport.so (0.3.1-5c5d950) Module found: /usr/local/lib/SoapySDR/modules0.8/libsdrPlaySupport.so (0.3.0-14ec39e) Available factories... audio, hackrf, lime, multi, netsdr, remote, rtlsdr, sdrplay Available converters...

• CF32 -> [CF32, CS16, CS8, CU16, CU8]
• CS16 -> [CF32, CS16, CS8, CU16, CU8]
• CS32 -> [CS32]
• CS8 -> [CF32, CS16, CS8, CU16, CU8]
• CU16 -> [CF32, CS16, CS8]
• CU8 -> [CF32, CS16, CS8]
• F32 -> [F32, S16, S8, U16, U8]
• S16 -> [F32, S16, S8, U16, U8]
• S32 -> [S32]
• S8 -> [F32, S16, S8, U16, U8]
• U16 -> [F32, S16, S8]
• U8 -> [F32, S16, S8]

If that is of any use.

[alfille]

I don't know what the IP address is so strange for the remote device.

[BatchDrake]

Hey, sorry for not getting back to you earlier. The log was truncated again, so I guess for whatever reason valgrind is not doing what it should do. I'll try with my RasPi 3 later today.

The crash inside init_sources only tells me that the crash is happening inside SoapySDR somehow, during device detection (the backtraces you provided earlier seem to be related to an allocation?). I have to say, it would not be the first time I get a crash on startup because a buggy module (in my system, I get random crashes because of the HackRF module, both in SigDigger and gqrx).

Regarding the strange IP, that's actually an IPv6 address, which is 128 (i.e. 16 bytes) long. You should be able to change it though

[BatchDrake]

Can't reproduce in Pi 3 A+. Installed with all modules without issue. Even captured with RTL-SDR. OS was a regular Raspbian.

[alfille]

Time for me to investigate my environment. I have a number of PIs all running SoapyRemote with RTLSDR, PlutoSDR LimeSDR HackRF and an RSP1 clone. I suspect that one of them is the culprit.

[BatchDrake]

I am closing this issue due inactivity. Feel free to reopen it if the problem persists.