Packages for Ubuntu 16.10


#1

Hi guys, in particular @joshblum

Due to the recent UHD PPA updates I went on and built the relevant packages (gnuradio and up) for Ubuntu 16.10. Unfortunately, the known crash issue has not been resolved in the latest UHD so the packages are pretty much useless for anything that has a runtime link to UHD.

Therefore, I have rebuilt gr-osmosdr with UHD support disabled and things are now working fine – well at least gqrx.

I hope it’s OK that I did this without asking first. I really see no choice since programs like gqrx crash without any possibility to work around it, except disabling UHD support in gr-osmosdr.


LimeSDR with Gqrx is working!
#2

That sucks, but I understand. I should also have to rebuild SoapyUHD and gnuradio (gr-uhd), as technically the ABI changed. I guess it would still crash due to the boost issue. If I get a moment. I will see what my yakkety VM does.


#3

Well, at least the problem is 100% reproducible and it looks like it occurs when probing for devices:

Starting program: /usr/bin/gqrx 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
linux; GNU C++ version 6.2.0 20160824; Boost_106100; UHD_003.009.005-0-unknown

[New Thread 0x7fffe3dd6700 (LWP 10235)]
Controlport disabled
No user supplied config file. Using "default.conf"
[New Thread 0x7fffdbb8a700 (LWP 10236)]
gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10
built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya 
FM demod gain: 1.52789
IQ DCR alpha: 1.04166e-05
[New Thread 0x7fffdb161700 (LWP 10237)]
Using audio backend: N/A
BookmarksFile is /home/alc/.config/gqrx/bookmarks.csv
[New Thread 0x7fffd93d1700 (LWP 10238)]
[Thread 0x7fffd93d1700 (LWP 10238) exited]
[New Thread 0x7fffd93d1700 (LWP 10239)]
[Thread 0x7fffd93d1700 (LWP 10239) exited]
[New Thread 0x7fffd93d1700 (LWP 10240)]
[Thread 0x7fffd93d1700 (LWP 10240) exited]
[New Thread 0x7fffd93d1700 (LWP 10241)]
[Thread 0x7fffd93d1700 (LWP 10241) exited]
[New Thread 0x7fffd93d1700 (LWP 10242)]
[New Thread 0x7fffd8bd0700 (LWP 10243)]
[Thread 0x7fffd8bd0700 (LWP 10243) exited]
[Thread 0x7fffd93d1700 (LWP 10242) exited]

Thread 1 "gqrx" received signal SIGSEGV, Segmentation fault.
0x00007ffff6df4188 in boost::asio::detail::task_io_service::shutdown_service()
    () from /usr/lib/x86_64-linux-gnu/libgnuradio-blocks.so.3.7.10
(gdb) bt
#0  0x00007ffff6df4188 in boost::asio::detail::task_io_service::shutdown_service() () from /usr/lib/x86_64-linux-gnu/libgnuradio-blocks.so.3.7.10
#1  0x00007ffff6df6fb9 in boost::asio::detail::resolver_service_base::shutdown_service() () from /usr/lib/x86_64-linux-gnu/libgnuradio-blocks.so.3.7.10
#2  0x00007ffff12dd159 in ?? () from /usr/lib/x86_64-linux-gnu/libuhd.so.003
#3  0x00007ffff151de3a in ?? () from /usr/lib/x86_64-linux-gnu/libuhd.so.003
#4  0x00007ffff152e2a1 in ?? () from /usr/lib/x86_64-linux-gnu/libuhd.so.003
#5  0x00007ffff152cfee in ?? () from /usr/lib/x86_64-linux-gnu/libuhd.so.003
#6  0x00007ffff14ef360 in ?? () from /usr/lib/x86_64-linux-gnu/libuhd.so.003
#7  0x00007ffff1699f13 in uhd::device::find(uhd::device_addr_t const&, uhd::device::device_filter_t) () from /usr/lib/x86_64-linux-gnu/libuhd.so.003
#8  0x00007ffff6190443 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libgnuradio-osmosdr.so.0.1.4
#9  0x00007ffff6167a1b in osmosdr::device::find(osmosdr::device_t const&) ()
   from /usr/lib/x86_64-linux-gnu/libgnuradio-osmosdr.so.0.1.4
#10 0x0000555555699bdb in CIoConfig::getDeviceList(std::map<QString, QVariant, std::less<QString>, std::allocator<std::pair<QString const, QVariant> > >&) ()
#11 0x000055555561302c in MainWindow::MainWindow(QString, bool, QWidget*) ()
#12 0x00005555555b505a in main ()
(gdb)

#4
Boost_106100; UHD_003.009.005-0-unknown

That print seems completely wrong. It should say UHD_003.010.001.001-release So thats the old uhd library, maybe some package got renamed


#5

I just copy & pasted from an old email from when I tested using 16.10 packages. The latest binaries from PPA also point to boost::asio::detail::task_io_service::shutdown_service()


#6

Just for a data point - I ran uhd_usrp_probe and uhd_find_devices on a yakkety VM for both packages (ubuntu and from ppa) and neither command crashes. I will have to see what the osmosdr blocks do. I wonder if there is a synergy between one of the osmo devices using boost asio and uhd.


#7

Hmm, it could be that the UHD applications catch the exceptions.


#8

Just as some other data points:

  • SoapySDR with uhd support is fine as well.
  • I tried disabling everything in grosmosdr except for uhd, and I still see the crash.
  • Disabling uhd and enabling soapy, grosmosdr can discover b200 through soapysdr

I bet it has something to do with ASIO being used by both uhd and gnuradio blocks…

In other news, I’ve managed to get limesdr displaying nicely in gqrx devices list:


#9

Thanks for the update, Josh.

I will be looking into adding gr-iio support to gr-osmosdr in the coming weeks and will try to see if I can spot anything in the UHD code. I know the RFSpace backend has the option of using boost asio, so what you say sounds plausible.

I will also have to tell Dimitri about my patches that we have in the PPA. I’ve got good feedback from field testing so they work well.

Does it mean that soapy devices will be included in the gr-osmosdr device list? That would be nice :smile:

On a different note, I am wondering if you are aware of any discussions regarding the future of gr-osmosdr? It seems to me that soapysdr with a gr-soapy block would be more feasible way forward. I am yet to use it in a real project, but I think the plugin architecture and the fact that it is available outside GNU Radio makes it more fit for the purpose.


#10

Does it mean that soapy devices will be included in the gr-osmosdr device list? That would be nice :smile:

Yes. I was wondering why they were missing. Turns out that I forgot to put my ifdefs in the devices code.

On a different note, I am wondering if you are aware of any discussions regarding the future of gr-osmosdr? It seems to me that soapysdr with a gr-soapy block would be more feasible way forward. I am yet to use it in a real project, but I think the plugin architecture and the fact that it is available outside GNU Radio makes it more fit for the purpose.

I’m not aware of any discussion. I was sticking with gr-osmosdr because its a well known API that many people use and build. And with the soapy support, it is effectively modular. You could configure gr-osmosdr for only soapy support and you would still be able to support most of the devices out there.

I think that a gr-soapy source/sink in mainline gnuradio would be tremendously helpful in terms of developer burden and supporting hardware. But its just a question of what the community is willing to use. But if there was interest, I would be supportive.


#11

This would seem to make a lot of sense.


Lime Suite v17.01.1 tag and binaries