This is with a version of rtl-sdr I got by git last night and OpenBSD 5.2 (current release). 5.2 has some pthreads fixing so I waited until I bought another computer and loaded it. Are the crashes related to threads? I don't know, but possibly. It didn't work with OpenBSD 5.0 either.
rtl_fm crashes and uses threads rtl_adsb crashes and uses threads rtl_tcp doesn't crash, uses threads, actually stops on ctrl-c rtl_test doesn't crash, doesn't use threads, won't stop rtl_eeprom doesn't crash, doesn't use threads, ends normally
I'm not real practiced using gdb but I tried looking at a couple of core files, here's a run of rtl_fm:
rtl_fm -f 162550000 -N - | play -t raw -r 24k -e signed-integer -b 16 -c 1 -V1 -
-: (raw)
Encoding: Signed PCM Channels: 1 @ 16-bit Samplerate: 24000Hz Replaygain: off Duration: unknown
In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000013
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Oversampling input by: 42x. Oversampling output by: 1x. Buffer size: 8.13ms Tuned to 162802000 Hz. Sampling at 1008000 Hz. Output at 24000 Hz. Exact sample rate is: 1008000.009613 Hz Tuner gain set to automatic. In:0.00% 00:00:00.00 [00:00:00.00] Out:0 [ | ] Clip:0 Done. Abort (core dumped)
d530# gdb -c rtl_fm.core /usr/local/bin/rtl_fm GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-openbsd5.2"... Core was generated by `rtl_fm'. Program terminated with signal 6, Aborted. Reading symbols from /usr/lib/libpthread.so.16.0...done. Loaded symbols for /usr/lib/libpthread.so.16.0 Reading symbols from /usr/lib/libm.so.7.0...done. Loaded symbols for /usr/lib/libm.so.7.0 Reading symbols from /usr/local/lib/librtlsdr.so.0.0...done. Loaded symbols for /usr/local/lib/librtlsdr.so.0.0 Reading symbols from /usr/local/lib/libusb-1.0.so.1.0...done. Loaded symbols for /usr/local/lib/libusb-1.0.so.1.0 Symbols already loaded for /usr/lib/libpthread.so.16.0 Reading symbols from /usr/lib/libc.so.65.0...done. Loaded symbols for /usr/lib/libc.so.65.0 Loaded symbols for /usr/libexec/ld.so #0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0 (gdb) bt #0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0 #1 0x0ac29545 in abort () at /usr/src/lib/libc/stdlib/abort.c:68 #2 0x005e9298 in pthread_mutex_unlock (mutexp=0x3c003d8c) at /usr/src/lib/librthread/rthread_sync.c:218 #3 0x1c00266e in full_demod (fm=0xcfa2de5c) at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:583 #4 0x1c0028ff in demod_thread_fn (arg=0xcfa2de5c) at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:641 #5 0x005ebc2e in _rthread_start (v=0x84da4c00) at /usr/src/lib/librthread/rthread.c:111 #6 0x0aba62e9 in __tfork_thread () from /usr/lib/libc.so.65.0
The backtrace (bt) shows that it dies trying to do a mutex_unlock (I think). rtl_tcp also does a mutex_unlock and it doesn't crash. I'm probably reading it wrong for all I know. I don't know what's causing the signal 6 either.
I'd also like to get the -lrt of of the cmake files. OpenBSD doesn't use or have lrt, it works without. I can edit it out and compile, but every time I run cmake again, I have to edit the files again.
Alan
----- Radio Astronomy - the ultimate DX
On 2013-04-17, Alan Corey alancorey@yahoo.com wrote:
This is with a version of rtl-sdr I got by git last night and OpenBSD 5.2 (current release). 5.2 has some pthreads fixing so I waited until I bought another computer and loaded it. Are the crashes related to threads? I don't know, but possibly. It didn't work with OpenBSD 5.0 either.
rtl_fm crashes and uses threads rtl_adsb crashes and uses threads rtl_tcp doesn't crash, uses threads, actually stops on ctrl-c rtl_test doesn't crash, doesn't use threads, won't stop rtl_eeprom doesn't crash, doesn't use threads, ends normally
[snip]
I've just got hold of a card and looking into this.
(gdb) bt #0 0x0abbd98d in kill () from /usr/lib/libc.so.65.0 #1 0x0ac29545 in abort () at /usr/src/lib/libc/stdlib/abort.c:68 #2 0x005e9298 in pthread_mutex_unlock (mutexp=0x3c003d8c) at /usr/src/lib/librthread/rthread_sync.c:218 #3 0x1c00266e in full_demod (fm=0xcfa2de5c) at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:583 #4 0x1c0028ff in demod_thread_fn (arg=0xcfa2de5c) at /usr/src/misc/osmocom/2013-04-15/rtl-sdr/src/rtl_fm.c:641 #5 0x005ebc2e in _rthread_start (v=0x84da4c00) at /usr/src/lib/librthread/rthread.c:111 #6 0x0aba62e9 in __tfork_thread () from /usr/lib/libc.so.65.0
By specification, pthread_mutex_unlock() has undefined behaviour when unlocking a mutex which is already unlocked.
Currently OpenBSD's "undefined behaviour" in this case is to immediately abort(), which has helped debug problems with some threaded programs.
You can change this behaviour by hacking librthread/rthread_sync.c:218 and building/installing new librthread, this gets rid of the crash but does not make things work properly; like rtl_test, rtl_fm doesn't stop when you ^C. I don't get any output from rtl_fm instead I get high system cpu usage. I suspect this is some issue (quite possibly kernel driver) with bulk transfers.
rtl_test doesn't work well for me. It starts up but
$ rtl_test Found 1 device(s): 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle Found Rafael Micro R820T tuner Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
Info: This tool will continuously read from the device, and report if samples get lost. If you observe no further output, everything is fine.
Reading samples in async mode... lost at least 1228 bytes lost at least 1924 bytes lost at least 1892 bytes lost at least 2588 bytes lost at least 1648 bytes [...]
Notably the two programs which do seem to work correctly are rtl_eeprom and rtl_tcp (at least I get some data from rtl_tcp but don't have anything setup to use it yet) - notably these two do *not* use rtlsdr_read_sync i.e. bulk transfers.
I'd also like to get the -lrt of of the cmake files. OpenBSD doesn't use or have lrt, it works without. I can edit it out and compile, but every time I run cmake again, I have to edit the files again.
OpenBSD isn't the only system which has the realtime functions in libc; this might be more generally applicable but note I have not tested it on a system which *does* have librt.
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index 6b23395..2afb494 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -101,12 +101,21 @@ target_link_libraries(rtl_adsb rtlsdr_shared if(UNIX) target_link_libraries(rtl_fm m) target_link_libraries(rtl_adsb m) -if(APPLE) - target_link_libraries(rtl_test m) -else() - target_link_libraries(rtl_test m rt) -endif() -endif() + +include(CheckFunctionExists) +check_function_exists(clock_gettime LIBRT_LIBC_HAS_CLOCK_GETTIME) +if(LIBRT_LIBC_HAS_CLOCK_GETTIME) + set(LIBRT_LIBRARIES) + set(LIBRT_LIB_FOUND TRUE) +else(LIBRT_LIBC_HAS_CLOCK_GETTIME) + find_library(LIBRT_LIBRARIES NAMES rt ) + if(LIBRT_LIBRARIES) + set(LIBRT_LIBRARIES TRUE) + endif(LIBRT_LIBRARIES) +endif(LIBRT_LIBC_HAS_CLOCK_GETTIME) + +target_link_libraries(rtl_test m ${LIBRT_LIBRARIES}) +endif(UNIX)
if(WIN32) target_link_libraries(rtl_sdr libgetopt_static) diff --git a/src/rtl_test.c b/src/rtl_test.c index f5a56b8..f84d453 100644 --- a/src/rtl_test.c +++ b/src/rtl_test.c @@ -131,7 +131,7 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx) } ppm_count += (int64_t)len; #ifndef _WIN32 - #ifndef __APPLE__ + #ifdef CLOCK_REALTIME clock_gettime(CLOCK_REALTIME, &ppm_now); #else gettimeofday(&tv, NULL); @@ -143,7 +143,7 @@ static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx) ns += (int64_t)(ppm_now.tv_nsec - ppm_recent.tv_nsec); printf("real sample rate: %i\n", (int)((1000000000L * ppm_count / 2L) / ns)); - #ifndef __APPLE__ + #ifdef CLOCK_REALTIME clock_gettime(CLOCK_REALTIME, &ppm_recent); #else gettimeofday(&tv, NULL);
I've just got hold of a card and looking into this.
Do you mean a dongle? I got one of the $20 ones, which works pretty well in Windows with SDR# and RTL1090, so I bought a second one.
By specification, pthread_mutex_unlock() has undefined behaviour when unlocking a mutex which is already unlocked.
I wondered about that. If it wasn't either locking something already locked our unlocking something already unlocked. I stuck a bunch of extra printfs in the code and was trying to keep track of what it was doing. It works under Linux, but that's like saying a web page works fine in IE. Too sloppy to do otherwise.
Currently OpenBSD's "undefined behaviour" in this case is to immediately abort(), which has helped debug problems with some threaded programs.
You can change this behaviour by hacking librthread/rthread_sync.c:218 and building/installing new librthread, this gets rid of the crash but does not make things work properly; like rtl_test, rtl_fm doesn't stop when you ^C. I don't get any output from rtl_fm instead I get high system cpu usage. I suspect this is some issue (quite possibly kernel driver) with bulk transfers.
I wonder if the not stopping is because the low level acquisition, possibly a different thread, isn't getting stopped.
Info: This tool will continuously read from the device, and report if samples get lost. If you observe no further output, everything is fine.
I seem to always have samples getting lost, no matter what I do I think it's also supposed to give you a ppm adjustment figure, but I worked out mine from tuning in a few stations and seeing how far off frequency they were (with SDR#). One dongle is off 102 ppm, the other 62 ppm.
I forgot to mention it, but rtl_sdr (the simplest one) also doesn't work. I was looking at trying to adapt them to use the Gnu pth threads.
Notably the two programs which do seem to work correctly are rtl_eeprom and rtl_tcp (at least I get some data from rtl_tcp but don't have anything setup to use it yet) - notably these two do *not* use rtlsdr_read_sync i.e. bulk transfers.
There's a scanning client for rtl_tcp somebody wrote, but they did it in Python. It has one dependency that seems badly packaged. I don't have it working yet. I was thinking of writing a command line scanner in C that has hopefully no dependencies.
Are you sure your rtl_tcp is actually working? Mine stops after a while. You could test it by running SDR# on a Windows machine and having the source of that be the rtl_tcp on an OpenBSD box, just enter the IP address and port. I think it's a lot of network load for even 100baseTX though. There are also Gnuradio sources that can work from rtl_tcp.
OpenBSD isn't the only system which has the realtime functions in libc; this might be more generally applicable but note I have not tested it on a system which *does* have librt.
I could in principle do that. I can boot this box into an old Debian and try that.
Alan
On 2013/04/19 20:59, Alan Corey wrote:
I've just got hold of a card and looking into this.
Do you mean a dongle? I got one of the $20 ones, which works pretty well in Windows with SDR# and RTL1090, so I bought a second one.
Yes..
By specification, pthread_mutex_unlock() has undefined behaviour when unlocking a mutex which is already unlocked.
I wondered about that. If it wasn't either locking something already locked our unlocking something already unlocked. I stuck a bunch of extra printfs in the code and was trying to keep track of what it was doing. It works under Linux, but that's like saying a web page works fine in IE. Too sloppy to do otherwise.
Linux doesn't have this strict checking, it was specifically added to try to flush out bugs in programs using mutexes.
I wonder if the not stopping is because the low level acquisition, possibly a different thread, isn't getting stopped.
I've talked to another developer and we don't have good support for usb transfer with asynchronous events yet, somebody is already looking at this though. So for this side of things, it probably makes sense to wait until that's available as this is likely to be the main problem. (this is separate to the strict mutex checks mentioned above).
However I've just tried a few things in synchronous mode (rtl_test -S, rtl_sdr -S, and RTLSDR-Scanner which uses sync mode anyway) and those *do* seem to work.
Info: This tool will continuously read from the device, and report if samples get lost. If you observe no further output, everything is
fine.
I seem to always have samples getting lost, no matter what I do I think it's also supposed to give you a ppm adjustment figure, but I worked out mine from tuning in a few stations and seeing how far off frequency they were (with SDR#). One dongle is off 102 ppm, the other 62 ppm.
I forgot to mention it, but rtl_sdr (the simplest one) also doesn't work. I was looking at trying to adapt them to use the Gnu pth threads.
I think Pth won't help things on OpenBSD versions which already use kernel threads (5.2+), and unlikely to have helped earlier versions with userland threads either, the problem with userland thread implementations is how file descriptor blocking is handled.
Notably the two programs which do seem to work correctly are
rtl_eeprom
and rtl_tcp (at least I get some data from rtl_tcp but don't have anything setup to use it yet) - notably these two do *not* use rtlsdr_read_sync i.e. bulk transfers.
There's a scanning client for rtl_tcp somebody wrote, but they did it in Python. It has one dependency that seems badly packaged. I don't have it working yet. I was thinking of writing a command line scanner in C that has hopefully no dependencies.
Are you sure your rtl_tcp is actually working? Mine stops after a while. You could test it by running SDR# on a Windows machine and having the source of that be the rtl_tcp on an OpenBSD box, just enter the IP address and port. I think it's a lot of network load for even 100baseTX though.
Can't test these; I can only run Windows in VM (SDR# is broken if you have no audio device) or by dual booting my laptop (in which case I can't use rtl_tcp on OpenBSD as a source).
There are also Gnuradio sources that can work from rtl_tcp.
working on this ;)
I forgot to mention it, but rtl_sdr (the simplest one) also doesn't
work. I was looking at trying to adapt them to use the Gnu pth threads.
I think Pth won't help things on OpenBSD versions which already use kernel threads (5.2+), and unlikely to have helped earlier versions with userland threads either, the problem with userland thread implementations is how file descriptor blocking is handled.
I was trying to figure out whether pth was abandoned or just mature enough that it doesn't need any more updates. Looks like it's just mature. I was suspicious that it was somebody's thesis project.
This machine I'm trying to run on lately under 5.2 is dual core, and various things indicate that threads are less effective with multiple CPUs. It's my first dual core. Cost me $37.
There are also Gnuradio sources that can work from rtl_tcp.
working on this ;)
Me too, I failed a bunch of QA self-tests with segfaults but I'm not hearing from my post to the gnuradio-discuss list.
Your patch/diff for the cmake stuff works fine under OpenBSD, but not under Linux:
Linking C executable rtl_test /usr/bin/ld: cannot find -lTRUE collect2: ld returned 1 exit status make[2]: *** [src/rtl_test] Error 1 make[1]: *** [src/CMakeFiles/rtl_test.dir/all] Error 2 make: *** [all] Error 2
Gotta dereference that test result, sort of, somehow. I did the patching by hand with an editor but I'm fairly sure it's right. I did it in the OpenBSD partition, then copied to the Linux partition.
The sync/async stuff is interesting. I was assuming it was somehow more radio-related, like sync detection or sync related to the A/D process than USB sync.
Alan
On 2013/04/20 19:45, Alan Corey wrote:
I forgot to mention it, but rtl_sdr (the simplest one) also doesn't work. I was looking at trying to adapt them to use the Gnu pth threads.
I think Pth won't help things on OpenBSD versions which already use kernel threads (5.2+), and unlikely to have helped earlier versions with userland threads either, the problem with userland thread implementations is how file descriptor blocking is handled.
I was trying to figure out whether pth was abandoned or just mature enough that it doesn't need any more updates. Looks like it's just mature. I was suspicious that it was somebody's thesis project.
It's not all that much needed now that most unix-like OS have posix threads support..
Your patch/diff for the cmake stuff works fine under OpenBSD, but not under Linux:
bleh, silly mistake ;)
OK - just setup an fc18 box to test it; here's a fixed version.
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt index 4b91a4b..4cc77fc 100644 --- a/src/CMakeLists.txt +++ b/src/CMakeLists.txt @@ -101,12 +101,17 @@ target_link_libraries(rtl_adsb rtlsdr_shared if(UNIX) target_link_libraries(rtl_fm m) target_link_libraries(rtl_adsb m) -if(APPLE) - target_link_libraries(rtl_test m) -else() - target_link_libraries(rtl_test m rt) -endif() -endif() + +include(CheckFunctionExists) +check_function_exists(clock_gettime LIBRT_LIBC_HAS_CLOCK_GETTIME) +if(LIBRT_LIBC_HAS_CLOCK_GETTIME) + set(LIBRT_LIBRARIES) +else(LIBRT_LIBC_HAS_CLOCK_GETTIME) + find_library(LIBRT_LIBRARIES NAMES rt) +endif(LIBRT_LIBC_HAS_CLOCK_GETTIME) + +target_link_libraries(rtl_test m ${LIBRT_LIBRARIES}) +endif(UNIX)
if(WIN32) target_link_libraries(rtl_sdr libgetopt_static)
On 04/20/2013 05:59 AM, Alan Corey wrote:
I've just got hold of a card and looking into this.
Do you mean a dongle? I got one of the $20 ones, which works pretty well in Windows with SDR# and RTL1090, so I bought a second one.
By specification, pthread_mutex_unlock() has undefined behaviour when unlocking a mutex which is already unlocked.
Note also that rtl_fm uses mutexes as semaphores/condition variables, it locks mutexes in one thread and unlocks them in another thread - which is undefined behavior (Except if the mutex is recursive or error checking, in which case pthread_mutex_unlock must detect this situation and return an error).
You're only supposed to unlock a mutex by the same thread that locked it, and it's possible OpenBSD bails out if you do otherwise.
On 2013/05/09 13:30, noselasd@fiane.dyndns.org wrote:
On 04/20/2013 05:59 AM, Alan Corey wrote:
I've just got hold of a card and looking into this.
Do you mean a dongle? I got one of the $20 ones, which works pretty well in Windows with SDR# and RTL1090, so I bought a second one.
By specification, pthread_mutex_unlock() has undefined behaviour when unlocking a mutex which is already unlocked.
Note also that rtl_fm uses mutexes as semaphores/condition variables, it locks mutexes in one thread and unlocks them in another thread - which is undefined behavior (Except if the mutex is recursive or error checking, in which case pthread_mutex_unlock must detect this situation and return an error).
You're only supposed to unlock a mutex by the same thread that locked it, and it's possible OpenBSD bails out if you do otherwise.
Is there a reason for doing it this way rather than using sem_post and sem_wait?
I think I've fixed all the problems with rtl_fm. It does not use the async helper functions any more. For my purposes async mode is broken. No clue what happened, but when you re-turn it freezes up on rtlsdr_demod_read_reg(dev, 0x0a, 0x01, 1); line 476 of librtlsdr.c. The new code is still multithreaded and should be just as fast.
My patch is at https://github.com/keenerd/rtl-sdr
It would be nice to hear if this fixes the OpenBSD problems, and a confirmation that the new code still runs under windows.
-Kyle http://kmkeen.com
keenerd wrote:
I think I've fixed all the problems with rtl_fm. It does not use the async helper functions any more. For my purposes async mode is broken. No clue what happened, but when you re-turn it freezes up on rtlsdr_demod_read_reg(dev, 0x0a, 0x01, 1); line 476 of librtlsdr.c.
The OpenBSD kernel doesn't currently offer any async API that libusb can use, so libusb has to emulate the async behavior as best it can, and it is by no means perfect.
If you have a chance, I would very much like to work with you today, tomorrow and/or on Tuesday in order to look more closely into this. I have some ideas if you are up for it? After Tuesday I have no chance for a few weeks or so.
//Peter
On 8/18/13, Peter Stuge peter@stuge.se wrote:
If you have a chance, I would very much like to work with you today, tomorrow and/or on Tuesday in order to look more closely into this. I have some ideas if you are up for it?
Sure, I'll be in ##rtlsdr on Freenode today. Not sure how much help I can be though. I still don't know much about libusb or librtlsdr yet.
-Kyle http://kmkeen.com
-
Alan Corey -
keenerd -
noselasd＠fiane.dyndns.org -
Peter Stuge -
Stuart Henderson