merbanan
rtl_433 does not run and exits with no error message
rtl_433 does not run and exits with no error message.
On Ubuntu-20.04 using rtl_433 from apt:
$ rtl_433 -d driver=hackrf
rtl_433 version unknown inputs file rtl_tcp RTL-SDR SoapySDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "rtl_433.conf"...
Trying conf file at "/home/tom/.config/rtl_433/rtl_433.conf"...
Trying conf file at "/usr/local/etc/rtl_433/rtl_433.conf"...
Trying conf file at "/etc/rtl_433/rtl_433.conf"...
Registered 122 out of 149 device decoding protocols [ 1-4 8 11-12 15-17 19-21 23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 ]
$ echo $?
1
$
On windows, using any of rtl_433.exe, rtl_433-rtlsdr-soapysdr.exe, rtl_433-rtlsdr-soapysdr-tls.exe from the current releases on github:
Downloads\rtl_433-win-msvc-x64-21.12>rtl_433-rtlsdr-soapysdr.exe -d driver=hackrf
rtl_433 version 21.12 branch at 202112141644 inputs file rtl_tcp RTL-SDR SoapySDR
Use -h for usage help and see https://triq.org/ for documentation.
Trying conf file at "C:\Users\Tom\Downloads\rtl_433-win-msvc-x64-21.12\rtl_433.conf"...
Trying conf file at "C:\Users\Tom\AppData\Local\rtl_433\rtl_433.conf"...
Trying conf file at "C:\ProgramData\rtl_433\rtl_433.conf"...
Registered 176 out of 207 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-207 ]
>
Thanks! That's SoapySDRDevice_makeStrArgs(dev_query) crashing. I'll look into it.
It's somewhat odd. SoapySDR::Device::make() throws at https://github.com/pothosware/SoapySDR/blob/master/lib/Factory.cpp#L183 which is fine and expected. But then SoapySDRDevice_makeStrArgs() at https://github.com/pothosware/SoapySDR/blob/master/lib/FactoryC.cpp#L39 seems not to catch and leaks the exception as sigabrt.
A workaround for you: make sure there is actually a device that can be found and opened. That error is just in the "no such device" case.
It seems to only happen if a SoapySDR::Kwargs (i.e. std::map<std::string, std::string>) is in scope.
The destructor of std::map seems to panic on throw. Not sure what to do about it, scoping or deleting that map works -- but is not a proper solution.
Seems to be a GCC bug (gcc-mp-11 is 11.2.0), Clang works fine.
#include <stdio.h>
#include <SoapySDR/Device.h>
int main(int argc, char *argv[])
{
printf("calling, expect SIGABRT...\n");
SoapySDRDevice *d = SoapySDRDevice_makeStrArgs(argv[1]);
printf("it worked, dev= %p\n", d);
}
gives
$ gcc-mp-11 -Wall -I/usr/local/include -L/usr/local/lib -lSoapySDR -o minimal minimal.c && ./minimal driver=rtlsdr
...
it worked, dev= 0x7f954a416f50
and
$ gcc-mp-11 -Wall -I/usr/local/include -L/usr/local/lib -lSoapySDR -o minimal minimal.c && ./minimal driver=nosuch
calling, expect SIGABRT...
[1] 20138 abort ./minimal driver=nosuch
I guess there is nothing wrong with rtl_433 or SoapySDR and really no good workaround.
Could be that GCC or the RT-lib (libgcc_s) has problems freeing the std::map on throw.
Wow, thanks for root causing this. Random thought, but could the SoapySDR lib be ~~accidentally exporting std::map symbols which were~~ compiled from a different compiler, and they're not ABI compatible with the std::map in the application, so when a map is passed between compilation units bad things can happen?
As for "no such device" - I'm not sure how to debug this, but the SoapySDRUtil tool, and CubicSDR included with the Pothos installer both seem to find the device. Is there a way to debug within rtl_433?
Yes, C++ is known for unstable ABI. I have seen this in broken automatic destructors with polymorphism/virtuals table layout, and exceptions would seem similar. But I really don't have a clue about C++ and where/how the exception unwinding is done. I did compile Soapy with different compilers and the only thing that triggers the bug is rtl_433 built with GCC (even when Soapy is built with the same GCC).
You can try just -d "" to pick the first available Soapy device.
Ah well, linking with -static-libgcc works. So it's the shared libgcc that crashes things. Curiously you would prefer the shared (system wide installed) libgcc to prevent problems with e.g. exceptions usually.
-d "" has the same behavior. This also seems to fail on the https://github.com/hertzg/rtl_433_docker docker images. does this affect all prebuilt binaries?
I'll try compiling with clang
Bottom line seems to be "libSoapySDR doesn't link libgcc, linking of libSoapySDR and libgcc in applications breaks exception handling". But how could that not be noticed? Most people use distro packaged GCC, not Clang. Is that linking or the behaviour a recent change? Can we replicate that condition or is there more involved? It'll take some days to run scenarios on different platform and compilers ;)
If -d "" doesn't work but SoapySDRUtil --make="" works then something else is wrong. Different libraries with a different module path?
Some updates, I got it to work on linux compiled with clang!
- with
-d ""it seems to find some other (not real) device first, and not my hackrf - so it is a different failure.
Registered 185 out of 217 device decoding protocols [ 1-4 8 11-12 15-17 19-23 25-26 29-36 38-60 63 67-71 73-100 102-105 108-116 119 121 124-128 130-149 151-161 163-168 170-175 177-197 199 201-215 217 ]
[INFO] [UHD] linux; GNU C++ version 9.2.1 20200304; Boost_107100; UHD_3.15.0.0-2build5
[ERROR] avahi_service_browser_new() failed: Bad state
[INFO] Using format CS16.
Sample rate set to 2048000 S/s.
Tuner set to automatic gain.
Tuner gain set to Auto.
Failed to activate stream
This message is still not very helpful.
- If I just don't have the hackrf plugged in, or forget to
sudo- it fails with the same behavior as originally (just exits without any message at all), but exit code is 2 instead of 1. There should really be somepermission deniedordevice not foundlog here to help people out. Not sure if there is supposed to be and it's just failing early for some other reason...
A bit unrelated, but every time I do get it to work now, I have to power cycle the device between running rtl_433, otherwise on the next run it exits with:
[INFO] Opening HackRF One #0 75b068dc324ead07...
Sample rate set to 2048000 S/s.
Tuner gain set to Auto.
Tuned to 433.000MHz.
WARNING: sync read failed. -1
WARNING: sync read failed. -1
Async read stalled, exiting!
WARNING: sync read failed. -1
Where are we on this? It doesn't really seem like an rtl_433 bug, and I don't see what we could/should do about it. There are packaging bugs lurking, and perhaps soapy. So I think we should close this.
