search

gqrx-sdr / gqrx

Software defined radio receiver powered by GNU Radio and Qt.
http://gqrx.dk
GNU General Public License v3.0
3.02k stars 539 forks source link

GQRX Crash: rtlsdr_read_async returned with -5 #162

Closed robotastic closed 10 years ago

robotastic commented 10 years ago

I am having an error with GQRX crashing about 2 seconds after I hit the button to go live. It is a pretty clean system running GR3.7. It looks like a couple of other people are having this problem: http://lists.gnu.org/archive/html/discuss-gnuradio/2014-03/msg00468.html

I have tried both the Master versions of GQRX and GR-OsmoSDR and the release versions and that hasn't helped. Running as SUDO doesn't seem to help. Anything else I should try?

linux; GNU C++ version 4.7.3; Boost_104900; UHD_003.007.000-1-ga8caec5f

gr-osmosdr v0.1.0-78-g1e8b45d0 (0.1.1git) gnuradio 3.7.3 built-in source types: file fcd rtl rtl_tcp uhd rfspace Using Volk machine: ssse3_64_orc gr-osmosdr v0.1.0-78-g1e8b45d0 (0.1.1git) gnuradio 3.7.3 built-in source types: file fcd rtl rtl_tcp uhd rfspace Using device #0 Realtek RTL2838UHIDIR SN: 00000001 Found Rafael Micro R820T tuner Exact sample rate is: 1500000.014901 Hz rtlsdr_read_async returned with -5 gqrx: pthread_mutex_lock.c:65: pthread_mutex_lock: Assertion `mutex->data.__owner == 0' failed. Aborted (core dumped)

csete commented 10 years ago

Have you updated rtl-sdr library before gr-osmosdr? Also, as mentioned in that email thread, it's unlikely that its a gqrx error since gqrx only uses generic gr-osmosdr API and does not talk to librtlsdr directly.

robotastic commented 10 years ago

I did. It is a clean install, so RTLSDR should be the latest version. Maybe I will try going down a version.

Sent from my iPhone

On Mar 21, 2014, at 4:56 PM, Alexandru Csete notifications@github.com wrote:

Have you updated rtl-sdr library before gr-osmosdr? Also, as mentioned in that email thread, it's unlikely a gqrx error since gqrx only uses generic gr-osmosdr API and does not talk to librtlsdr directly.

— Reply to this email directly or view it on GitHub.

csete commented 10 years ago

First try rtl_test / rtl_fm / rtl_sdr to check that the driver library works Then you can try osmocom_fft to see if the gr-osmosdr library works with rtlsdr.

If both check out then it is a gqrx issu, however, I can't image what I can or could have done to trigger such an error.

I'm updating my packages now but it will take a few hours before it's done.

csete commented 10 years ago

I have updated all my packages using pybombs. Latest librtlsdr, gnuradio, gr-osmosdr, ... works fine here.

robotastic commented 10 years ago

Weird... Osmo-fft works fine for me. I will try again on Monday I left the machine at work.

Sent from my iPhone

On Mar 21, 2014, at 6:01 PM, Alexandru Csete notifications@github.com wrote:

I have updated all my packages using pybombs. Latest librtlsdr, gnuradio, gr-osmosdr, ... works fine here.

— Reply to this email directly or view it on GitHub.

profknivre commented 10 years ago

Hi,

i can confirm, I've build gnuradio and rtlsdr on my machine using script from this address: http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource http://www.sbrac.org/files/build-gnuradio

on two machines: Ubuntu 13.04 - it crashes that way Ubuntu 13.10 - it works ok

but on both machines sdrsharp and osmocom_fft works fine, but gqrx crashes with segfault in libusb.

I'm using: Gqrx software defined radio receiver v2.2.0-119-gd71e

csete commented 10 years ago

What architecture? Also, could your try to build gqrx in debug mode, i.e. "qmake CONFIG+=debug"

profknivre commented 10 years ago

x86_64

already done, please take a look here: http://paste.ubuntu.com/7167747/ and here http://paste.ubuntu.com/7167761/

I hope this helps ;)

csete commented 10 years ago

I can see from your trace where the problem occurs. It happens during the forced RX reconfiguration, which was introduced as a workaround necessary with the rtlsdr/gnuradio combination. While this code could be disabled to let gqrx come up, it will happen again as soon as you change mode, filter or similar.

Similar problem was discovered with USRP B2xx but was fixed in UHD, see issue #145.

So, the bad news is that there is not much I can do about this in gqrx. It is a "feature" of gnuradio that one needs to reset/reconfigure the flow graph when changing e.g. demodulator.

It surprises me though that I have never seen this issue when I was using Xubuntu 13.04. Perhaps a newer libusb is available that works better?

profknivre commented 10 years ago

maybe I've mislead you, but in fact I'm using xubuntu not ubuntu, but I don't think they differ in library versions.

output of: apt-cache showpkg libusb-1.0-0 is here: http://paste.ubuntu.com/7168237/

robotastic commented 10 years ago

Could this have anything to do with this Lock/Unlock bug in GR 3.7? http://gnuradio.org/redmine/issues/598 I have the same problem in my 3.7 based C++ program, so I don't think it is Python specific.

robotastic commented 10 years ago

Forgot to add, that I did get everything to work fine on a different laptop with the same software stack installed, Ubuntu 13.10, GR 3.7, built through build-grnuadio script.

On the laptop I was getting this error I had previously tried to install that latest version of GQRX & GR-Osmosdr, I thought I had reverted everything, but I may not have.

csete commented 10 years ago

On Fri, Mar 28, 2014 at 6:04 PM, Luke Berndt notifications@github.comwrote:

Could this have anything to do with this Lock/Unlock bug in GR 3.7? http://gnuradio.org/redmine/issues/598 I have the same problem in my 3.7 based C++ program, so I don't think it is Python specific.

I don't think so since the error comes from libusb and already the first time lock/unlock happens.

robotastic commented 10 years ago

Good point! It does look like there is a know error in libusb. There is a patch mentioned in this thread. I will try it out.

http://www.libusb.org/ticket/131

csete commented 10 years ago

On Fri, Mar 28, 2014 at 7:37 PM, Luke Berndt notifications@github.comwrote:

Good point! It does look like there is a know error in libusb. There is a patch mentioned in this thread. I will try it out.

http://www.libusb.org/ticket/131

... except that you probably already have a later version, which is actually libusbx (a fork). Confused yet?

Alex

mnhauke commented 10 years ago

I had the same issue on openSUSE 13.1 64bit (kernel: 3.11.10-7-desktop). Updating libusb from the distribution supplied version 1.0.9 (vanilla from libusb.org) to 1.0.18 (libusbx/libusb from libusb.info) fixed the problem immediately.

mark-orion commented 10 years ago

I can confirm this problem on two machines running XUbuntu 12.04 64bit. And osmocom_fft is working here too. The same with starting rtl_tcp and connecting to the spectrum server from gqrx - no problem. The crash only happens when gqrx tries to connect to RTL_SDR directly. The error in the kernelbuffer says this: [21126.551948] gqrx[27906]: segfault at 44 ip 00007fa7d7a115e7 sp 00007fa773ffeb70 error 4 in libusb-1.0.so.0.1.0[7fa7d7a0c000+e000]

csete commented 10 years ago

I appreciate the feedback; however, as you can see from the last messages it can not be fixed in gqrx but by upgrading libusb.

mark-orion commented 10 years ago

Just upgraded libusb to 1.0.18 and it works. I updated the wrong library because I was not aware that there are two libusb websites.... :-(

csete commented 10 years ago

Yeah, there is libusb and libusbx (fork). I think they are about to be merged again, but who knows...

csete commented 10 years ago

Any protests if I close this? As I understand we are in agreement that upgrading libusb is the solution.

robotastic commented 10 years ago

Yep! Sorry I should have closed it.

Sent from my iPhone

On Apr 5, 2014, at 3:23 PM, Alexandru Csete notifications@github.com wrote:

Any protests if I close this? As I understand we are in agreement that upgrading libusb is the solution.

— Reply to this email directly or view it on GitHub.

magicalbeard commented 10 years ago

I know this issue is closed, but I am having the same problem after updating to libusb1.0.9.

csete commented 10 years ago

Yes, the problem was reported with libusb 1.0.9 and solved by upgrading to 1.0.18, so upgrading to 1.0.9 wont solve anything.

magicalbeard commented 10 years ago

Alright, my fault for some reason I was thinking 1.0.9 was the latest version. Updated to 1.0.18 and it is working great. I try reading harder next time.

sweetpineapple commented 9 years ago

I fellowed the step of http://www.linuxfromscratch.org/~krejzi/blfs-git/general/libusb.html to upgraded the libusb. But I am having the same problem.

stupoo commented 9 years ago

I can duplicate the problem,

My GQRX was working, I then snaped the RTL usb port , after re soldering a cable to the board I now get the described error after same amount of time. (it was working with the cracked pcb)

opps

Stuart

stupoo commented 9 years ago

Ow it turns out I hadn't broken it but had upgraded my lib boost in the middle and forgot ;-) as the dongle is working with some other parts of gnu radio and osmo sdr

Lib boost issue seems to be plaguing many users as some distros seem to have recently updated them .

Stuart

rfrail3 commented 8 years ago

I have the same error "rtlsdr_read_async returned with -5" on a Debian Wheezy and the problem was with libusb. Using the last version from backports libusb-1.0-0:amd64 2:1.0.19-1~bpo70+1 solved it.

Thanks for the info guys!

l29ah commented 2 years ago

libusb 1.0.26 here, getting this problem on a long usb cable once a while. Couldn't it just retry the data request instead of failing completely?