segfault when compiling under amd64 #72
Comments
|
It is easier to troubleshoot when you enable core dumps (see e.g. http://www.akadia.com/services/ora_enable_core.html). Then a core file will be created on a segfault. With the core file you can get a stack trace and possibly the code location where the problem occurs (see e.g. http://stackoverflow.com/questions/5115613/core-dump-file-analysis). This might help find the issue. This might also help: http://stackoverflow.com/questions/2549214/interpreting-segfault-messages |
|
bt full #0 0x00007f0c1e1fb294 in opendir () from /lib/x86_64-linux-gnu/libc.so.6 |
|
I have an idea - there's no permission to dir which is tried to open (by opendir) - but how to determine what file/dir is tried to open? Last call which can i modify is: libusb_init(&ctx); cnt = libusb_get_device_list(ctx, &list); |
|
DAMN IT!!!! open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) |
|
I think this actually is a bug: a program should never end with a segfault. In this case it seems to be caused by the rtlsdr library. I think the problem is here: https://github.com/merbanan/rtl_433/blob/master/src/librtlsdr.c#L1165-1167 Indeed you can prevent this segfault by setting permissions correctly, however it still is a bug. I was able to reproduce the the segfault by changing permissions on /dev/bus/usb and subsequently I could prevent the segfault by first checking the result from libusb_init to be OK before making the call to libusb_get_device_list. Unfortunetely this pattern is used all over librtlsdr, even in more recent versions on https://github.com/steve-m/librtlsdr/blob/master/src/librtlsdr.c (which I understand is the most recent version of librtlsdr). Currently rtl_433 contains its own copy of librtlsdr.c which is already 2 years old, we can fix it in there, or try to get the original librtlsdr.c updated and get that into rtl_433. Anyway: you did hit a bug in librtlsdr which should be fixed I think. |
|
If there aren't compatibility problems, I'd be in favor of a rtl_433 package that just had rtl_433 and the necessary build files that would let it be compiled against the librtlsdr that is built separately from the main rtl_sdr package. If people don't agree, then at a minimum, I think all the other rtl_ tools (frm, test, tcp, etc.) should be removed from rtl_433, because they are all old leaving just rtl_433 and librtlsdr. |
|
@rct Thanks for the references. Because the Osmocom page refers to the @steve-m repository I used that as a reference. I see the @keenerd repository uses the same pattern. I'm starting to wonder if this is indeed a bug, it's hard to imagine that such a seemingly obvious bug has made it through all that time. I will just file an issue on both and see what response I get. |
|
@rct About the way to restructure rtl_433: indeed at least the other rtl_* tools should be removed from rtl_433 as we now risk overwriting more recent rtl_* tools by doing a make install. I believe some rtl_433 forks already have done this. Also it would indeed be nice to be able to build against the "latest" librtlsdr, (librtlsdr-dev package), however this introduces an extra dependency on installed packages, or requires to download the latest librtlsdr sources and build them. This is easy for developers but rtl_433 is being used more and more with people who just want to type cmake and make and have the 'darn thing' run. Maybe we can add it as an option in the Cmake files and keep the possibility to use rtl_433 'embedded' version of librtlsdr (this way we can fix issues like this one without depending on the systems default installed librtlsdr). It would be good to have a look at the latest librtlsdr forks and integrate the "best" (most active and responsive) version. |
|
reinstructure rtl_433 - my proposal is create a completely new rtl_433 repo, where all of us will make own additions |
|
Hi there, What could be the problem. ~/ soapysdrutil --probe="hackrf" Soapy SDR -- the SDR abstraction library###################################################### Probe device hackrf Gives no Hackrf.... |
|
forgot this: |
|
Can you try a full debug build ( |
The result:
|
Does any have an idea why rtl_444 generates segfault? I use it under i386, but moved into amd64, githubbed clean repo, cmake, make, rtl_433 ->
Registering protocol[01] Rubicson Temperature Sensor
Registering protocol[02] Prologue Temperature Sensor
Registering protocol[03] Silvercrest Remote Control
Registering protocol[04] ELV EM 1000
Registering protocol[05] ELV WS 2000
Registering protocol[06] Waveman Switch Transmitter
Registering protocol[07] Steffen Switch Transmitter
Registering protocol[08] Acurite 5n1 Weather Station
Segfault
dmesg shows:
[14190.217587] rtl_433[21585]: segfault at 0 ip 00007fa33d944294 sp 00007fff96da4e90 error 4 in libc-2.13.so[7fa33d89c000+182000]
[14195.813128] rtl_433[21586]: segfault at 0 ip 00007f163b58d294 sp 00007fff494fab00 error 4 in libc-2.13.so[7f163b4e5000+182000]
[14220.146136] rtl_433[21592]: segfault at 0 ip 00007f67074c7294 sp 00007fff670af930 error 4 in libc-2.13.so[7f670741f000+182000]
[14857.105725] rtl_433[22594]: segfault at 0 ip 00007f5a2bb51294 sp 00007fff6edad4e0 error 4 in libc-2.13.so[7f5a2baa9000+182000]
The text was updated successfully, but these errors were encountered: