Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Immediate crash on Pi4 -- free error. #102

Closed
alfille opened this issue May 4, 2020 · 13 comments
Closed

Immediate crash on Pi4 -- free error. #102

alfille opened this issue May 4, 2020 · 13 comments

Comments

@alfille
Copy link

alfille commented May 4, 2020

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
Copy link
Owner

BatchDrake commented May 4, 2020 •
edited
Loading

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
Copy link
Author

alfille commented May 4, 2020

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
Copy link
Owner

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
Copy link
Author

alfille commented May 5, 2020

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

@BatchDrake
Copy link
Owner

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
Copy link
Author

alfille commented May 5, 2020

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

@alfille
Copy link
Author

alfille commented May 6, 2020

After 20 hours I get this:

crash.log

@alfille
Copy link
Author

alfille commented May 8, 2020

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
Copy link
Author

alfille commented May 8, 2020

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

@BatchDrake
Copy link
Owner

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
Copy link
Owner

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

@alfille
Copy link
Author

alfille commented May 9, 2020

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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@alfille @BatchDrake