bistromath / gr-air-modes

Gnuradio Mode-S/ADS-B radio
This project implements a Mode S receiver for the Gnuradio software-defined radio project. It is designed to receive Mode S transmissions from aircraft and decode them to a human-readable format, including ADS-B information messages such as position and a
GNU General Public License v3.0
442 stars 126 forks source link

modes_gui crashes when switching to osmocom source #75

Open devnulling opened 9 years ago

devnulling commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

lepido commented 9 years ago

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 commented 9 years ago

@mrivault: are you also on MacOS?

lepido commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 notifications@github.com 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 https://github.com/bistromath/gr-air-modes/issues/75#issuecomment-138453704 .

lepido commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 notifications@github.com 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 https://github.com/bistromath/gr-air-modes/issues/75#issuecomment-139302113 .

devnulling commented 9 years ago

@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 commented 9 years ago

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 commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 https://github.com/bistromath/gr-air-modes/issues/75#issuecomment-161349358 .

sbmueller commented 8 years ago

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