modes_gui crashes when switching to osmocom source #75

devnulling · 2015-08-21T20:36:19Z

When running modes_gui, the GUI will open, but switching to the osmocom source, it crashes with the following error. I've test this with a RTLSDR and BladeRF with the same result. modes_rx works fine.

$ modes_gui
Mac OS; Clang version 6.1.0 (clang-602.0.53); Boost_105900; UHD_003.008.005-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.8
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

libc++abi.dylib: terminating with uncaught exception of type swig::stop_iteration
Abort trap: 6

mrivault · 2015-08-30T22:49:39Z

hi, i have the same problem, with the same issues.
it works with modes_rx but with modes_gui when i select the osmocom had the application quit.
i have this message in my terminal.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

libc++abi.dylib: terminating with uncaught exception of type swig::stop_iteration

mrivault · 2015-08-31T19:06:14Z

Hi
I test with an N210 from ettus, with the same machine , and it works in rx and gui mode.

lepido · 2015-09-03T13:15:18Z

I am having the same issue. Any idea on how to overcome this?

This is my setup:

Mac OS 10.10.5
gnuradio 3.7.5 via macports
gr-air-modes via macports
SDR: hackrf

bistromath · 2015-09-03T17:57:53Z

@mrivault: are you also on MacOS?

lepido · 2015-09-04T13:07:47Z

I might add: For me it even crashes with the above mentioned QT exception even if my HackRF is not connected. It seems to me that the error occurs even before trying to access the device.

Here is the console output:
bash-3.2$ modes_gui
Mac OS; Clang version 6.1.0 (clang-602.0.53); Boost_105900; UHD_003.009.000-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.8
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy

FATAL: No supported devices found to pick from.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

libc++abi.dylib: terminating with uncaught exception of type swig::stop_iteration
Abort trap: 6

mrivault · 2015-09-07T21:07:10Z

yes i'm on Mac 10.9.5 Also i've made some test this week end, and it works on my VM (Vmware) of Kali 2.0. (installed on my mac) You should test if your system handle the hackrf : you enter on a terminal : hackrf_info if you have the info of the version etc... it meens that it's ok if not, you should try "sudo rmmod hackrf" and test again hackrf_info and it should work. otherwise, you should go on the gnuradio PyBOMBS wiki and download the right package : http://gnuradio.org/redmine/projects/pybombs/wiki bestregards Micha

lepido · 2015-09-08T06:53:07Z

I don't think that the hackrf is the problem. As others mentioned, using modes_rx wworks wthout a problem (and valid ADS-B messages are received). Although other application work fine. It seems that there is a problem with the GUI part. When you select OSMOCON as input device, it tries to run something which throws an exception. Wether hackrf is connected or not. Maybe it has something to do with unhiding the gain input field of the GUI? Unfortunately, for the GUI part no source code is provided - which means we cannot look into it and check what's causing this issue.

Just for completeness sake, here is my hackrf_info output and the QT error message with the hackrf connected:

Lab12007:~ lepifo$ hackrf_info
Found HackRF board 0:
USB descriptor string: 00000000000000004xxxxxxxxxxxxxxxx
Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2
Part ID Number: 0xa00xxxxx 0x00xxxxx
Serial Number: 0x00000000 0x00000000 0x4xxxxxxx 0x2xxxxxxx

Lab12007:~ lepido$ modes_gui
Mac OS; Clang version 6.1.0 (clang-602.0.53); Boost_105900; UHD_003.009.000-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.8
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy
Number of USB devices: 9
USB device 1d50:6089: 00000000000000004xxxxxxxxxxxxxxxx match
Using HackRF One with firmware 2015.07.2
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

libc++abi.dylib: terminating with uncaught exception of type swig::stop_iteration
Abort trap: 6

bistromath · 2015-09-08T15:35:59Z

The GUI code is all there, in modes_gui. It's all just python.

I can't replicate this as I don't currently have access to a Mac machine.

On Mon, Sep 7, 2015, 11:53 PM lepido [email protected] wrote:

I don't think that the hackrf is the problem. As others mentioned, using
modes_rx wworks wthout a problem (and valid ADS-B messages are received).
Although other application work fine. It seems that there is a problem with
the GUI part. When you select OSMOCON as input device, it tries to run
something which throws an exception. Wether hackrf is connected or not.
Maybe it has something to do with unhiding the gain input field of the GUI?
Unfortunately, for the GUI part no source code is provided - which means we
cannot look into it and check whats causing this issue.

Just for completeness sake, here is my hackrf_info output and the QT error
message with the hackrf connected:

Lab12007:~ lepifo$ hackrf_info
Found HackRF board 0:
USB descriptor string: 00000000000000004xxxxxxxxxxxxxxxx
Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2
Part ID Number: 0xa00xxxxx 0x00xxxxx
Serial Number: 0x00000000 0x00000000 0x4xxxxxxx 0x2xxxxxxx

Lab12007:~ lepido$ modes_gui
Mac OS; Clang version 6.1.0 (clang-602.0.53); Boost_105900;
UHD_003.009.000-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.8
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
airspy

Number of USB devices: 9
USB device 1d50:6089: 00000000000000004xxxxxxxxxxxxxxxx match
Using HackRF One with firmware 2015.07.2

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

libc++abi.dylib: terminating with uncaught exception of type
swig::stop_iteration
Abort trap: 6

—
Reply to this email directly or view it on GitHub
#75 (comment)
.

lepido · 2015-09-09T12:11:55Z

Thanks, bistromath. I missed that one.

Ok, what seems to be the problem is the code which populates the dropdown list for the sampling rates. Here is a (admittedly very ugly) hotfix. Replace these lines in apps/modes_gui:

238 self.rates = [rate.start() for rate in self.src.get_sample_rates()
239 if ((rate.start() % 2.e6) == 0)
240 or (rate.start() < 4.e6 and ((rate.start()%0.2e6) == 0))]

with this (values for HackRF One):

238 self.rates = [8.e6, 10.e6, 20.e6]

Although comment out / delete line 239 & 240. Recompile and it should work....

Now I have another "problem". The Google Maps map doesn't show up and it prints "undefined line 0: ReferenceError: Can't find variable: google" into the console. Any idea where this might come from?

CryptLabs · 2015-09-10T16:29:52Z

I'm having the same issue on my mac osx with bladerf
Mac OS; Clang version 6.0 (clang-600.0.56); Boost_105900; UHD_003.009.000-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.8
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy
Opening nuand bladeRF with device identifier string: "*:instance=0"
Serial # 3904...c0ed
FW v1.8.0 FPGA v0.3.4
Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

libc++abi.dylib: terminating with uncaught exception of type swig::stop_iteration

How can i fix this? i have been trying for a while to find a way.

bistromath · 2015-09-10T17:13:33Z

So the issue looks like a bug in Osmocom, it's throwing an exception when I
call get_sample_rates(). Why it would do that, I have no idea.

Can one of you open up a Python instance and type the following:

import osmosdr
a = osmosdr.source("")
b = [rate for rate in a.get_sample_rates()]

...and do this both with and without your HackRF/BladeRF/RTLSDR plugged in,
and cut and paste the result in this thread?

Thanks.
Nick

On Thu, Sep 10, 2015 at 9:29 AM Ali [email protected] wrote:

I'm having the same issue on my mac osx with bladerf
Mac OS; Clang version 6.0 (clang-600.0.56); Boost_105900;
UHD_003.009.000-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.8
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
airspy

Opening nuand bladeRF with device identifier string: "*:instance=0"
Serial # 3904...c0ed
FW v1.8.0 FPGA v0.3.4

Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt. You must
reimplement QApplication::notify() and catch all exceptions there.

libc++abi.dylib: terminating with uncaught exception of type
swig::stop_iteration

How can i fix this? i have been trying for a while to find a way.

—
Reply to this email directly or view it on GitHub
#75 (comment)
.

devnulling · 2015-09-10T17:58:31Z

@bistromath
I think there may be a bug with that last line of python code b = [rate for rate in a.get_sample_rates()]. I tried the same commands on a ubuntu machine and it resulted in the same swig error.

From RTLSDR:

$ python2.7
Python 2.7.10 (default, Aug 19 2015, 13:45:27) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import osmosdr
Mac OS; Clang version 6.1.0 (clang-602.0.53); Boost_105900; UHD_003.008.005-MacPorts-Release

>>> a = osmosdr.source("")
gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.8
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy 
Using device #0 Realtek RTL2838UHIDIR SN: 00000001
Found Rafael Micro R820T tuner
[R82XX] PLL not locked!
>>> b = [rate for rate in a.get_sample_rates()]
swig/python detected a memory leak of type 'swig::SwigPyIterator *', no destructor found.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: iter() returned non-iterator of type 'SwigPyObject'
>>>

From BladeRF:

$ python2.7
Python 2.7.10 (default, Aug 19 2015, 13:45:27) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import osmosdr
Mac OS; Clang version 6.1.0 (clang-602.0.53); Boost_105900; UHD_003.008.005-MacPorts-Release

>>> a = osmosdr.source("")
gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.8
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy 
Opening nuand bladeRF with device identifier string: "*:instance=0"
 Serial # cd38...0fdf
 FW v1.8.0 FPGA v0.1.2
>>> b = [rate for rate in a.get_sample_rates()]
swig/python detected a memory leak of type 'swig::SwigPyIterator *', no destructor found.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: iter() returned non-iterator of type 'SwigPyObject'
>>>

lepido · 2015-09-11T06:02:41Z

I can confirm, that the get_sample_rates() call will result in the memory leak issue on Mac OS as well (with and without a HackRF attached). Here is the output:

>>> b=[rate for rate in a.get_sample_rates()]
>>> swig/python detected a memory leak of type 'swig::SwigPyIterator *', no destructor found.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: iter() returned non-iterator of type 'SwigPyObject'

bhlaawckk · 2015-12-02T16:13:58Z

Hi,
I am testing my flow chart on Kali, with gnu 3.7 and nooelec r820t2. After executing the flowgrahp getting a blank console with an error message

Fatal: No supported devices found to pick from.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing due to gnuradio but #528.

/root/.gnuradio/prefs/vmcircbuf_default_factory: No such file or directory vmcircbuf_createfilemapping: createfilemapping is not availabe.

Any suggestions to fix it

bistromath · 2015-12-02T18:25:13Z

This happens when you choose the Osmocom source but don't have a device
plugged in, or don't have device permissions set up correctly. Follow the
directions to set up Osmocom for your device and try again.

On Wed, Dec 2, 2015 at 8:14 AM bhlaawckk [email protected] wrote:

Hi,
I am testing my flow chart on Kali, with gnu 3.7. After executing the
flowgrahp getting a blank console with an error message

Fatal: No supported devices found to pick from.

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing due to
gnuradio but #528.

/root/.gnuradio/prefs/vmcircbuf_default_factory: No such file or directory
vmcircbuf_createfilemapping: createfilemapping is not availabe.

Any suggestions to fix it

—
Reply to this email directly or view it on GitHub
#75 (comment)
.

sbmueller · 2016-06-19T15:18:27Z

Have the same issue on OS X. Osmocom works fine with gqrx and modes_rx, so the issue seems to be in modes_gui.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

modes_gui crashes when switching to osmocom source #75

modes_gui crashes when switching to osmocom source #75

devnulling commented Aug 21, 2015

mrivault commented Aug 30, 2015

mrivault commented Aug 31, 2015

lepido commented Sep 3, 2015

bistromath commented Sep 3, 2015

lepido commented Sep 4, 2015

mrivault commented Sep 7, 2015 via email

lepido commented Sep 8, 2015

bistromath commented Sep 8, 2015

lepido commented Sep 9, 2015

CryptLabs commented Sep 10, 2015

bistromath commented Sep 10, 2015

devnulling commented Sep 10, 2015

lepido commented Sep 11, 2015

bhlaawckk commented Dec 2, 2015

bistromath commented Dec 2, 2015

sbmueller commented Jun 19, 2016

modes_gui crashes when switching to osmocom source #75

modes_gui crashes when switching to osmocom source #75

Comments

devnulling commented Aug 21, 2015

mrivault commented Aug 30, 2015

mrivault commented Aug 31, 2015

lepido commented Sep 3, 2015

bistromath commented Sep 3, 2015

lepido commented Sep 4, 2015

mrivault commented Sep 7, 2015 via email

lepido commented Sep 8, 2015

bistromath commented Sep 8, 2015

lepido commented Sep 9, 2015

CryptLabs commented Sep 10, 2015

bistromath commented Sep 10, 2015

devnulling commented Sep 10, 2015

lepido commented Sep 11, 2015

bhlaawckk commented Dec 2, 2015

bistromath commented Dec 2, 2015

sbmueller commented Jun 19, 2016