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.

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

GQRX Crash: rtlsdr_read_async returned with -5 #162

Closed
robotastic opened this issue Mar 21, 2014 · 30 comments
Closed

GQRX Crash: rtlsdr_read_async returned with -5 #162

robotastic opened this issue Mar 21, 2014 · 30 comments

Comments

@robotastic
Copy link

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

csete commented Mar 21, 2014

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

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

csete commented Mar 21, 2014

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

csete commented Mar 21, 2014

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

@robotastic
Copy link
Author

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

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

csete commented Mar 28, 2014

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

@profknivre
Copy link

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

csete commented Mar 28, 2014

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

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

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

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

csete commented Mar 28, 2014

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

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

csete commented Mar 28, 2014

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

mnhauke commented Mar 28, 2014

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

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

csete commented Apr 3, 2014

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

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

csete commented Apr 3, 2014

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

@csete csete added the feature label Apr 5, 2014
@csete
Copy link
Collaborator

csete commented Apr 5, 2014

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

@robotastic
Copy link
Author

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

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

@csete
Copy link
Collaborator

csete commented Jul 18, 2014

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

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

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

stupoo commented Nov 4, 2014

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

stupoo commented Nov 5, 2014

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

rfrail3 commented May 26, 2016

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

l29ah commented Jul 4, 2022

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants