Crash after connect about soapyremote HOT 6 OPEN

I cant tell much from the backtrace, if you run this locally on the raspi when the server is running do you get the crash?

• SoapySDRUtil --find="driver=remote,remote=localhost"
• SoapySDRUtil --make="driver=remote,remote=localhost"

Whats the output of SoapySDRUtil --info on the raspi

Any duplication install stuff that would cause ABI issues on the raspi, like the same packages from source and from deb packages while compiling? Like libsoapysdr installed from a deb, and actually development files for soapysdr from source.

BTW, why are there ao many new threads being spawned and exited all the time?

Its parallelizing the discovery stuff with std::future(), which is spawning the reads

from soapyremote.

I don't think there are packages also present compiled from source. The Soapy and SDRplay stuff were installed from git source.
The --find and --make commands don't crash the server.

Below is output from SoapySDRUtil --info

######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.8.0-g980c2c50
API Version: v0.8.0
ABI Version: v0.8
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.8
Module found: /usr/local/lib/SoapySDR/modules0.8/libremoteSupport.so  (0.5.2-6d9bd82)
Module found: /usr/local/lib/SoapySDR/modules0.8/libsdrPlaySupport.so (0.3.0-14ec39e)
Available factories... remote, sdrplay
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS32 -> [CS32]
 -   CS8 -> [CF32, CS16, CS8, CU16, CU8]
 -  CU16 -> [CF32, CS16, CS8]
 -   CU8 -> [CF32, CS16, CS8]
 -   F32 -> [F32, S16, S8, U16, U8]
 -   S16 -> [F32, S16, S8, U16, U8]
 -   S32 -> [S32]
 -    S8 -> [F32, S16, S8, U16, U8]
 -   U16 -> [F32, S16, S8]
 -    U8 -> [F32, S16, S8]

from soapyremote.

The --find and --make commands don't crash the server.

Thats good to hear, this could easily be cubic calling a setting on the SoapySDRplay thats crashing rather than a general problem. There could be a call set segfaults on arm or something like that.

Running the server in gdb is the right idea. I think if you build SoapyRemote and SoapySDRplay with debug and get a backtrace, it should show the call. And maybe its something we can report to the respective issue tracker.

from soapyremote.

I have a similar issue:

root@raspberrypi:/home/pi# SoapySDRServer --bind
######################################################

Soapy Server -- Use any Soapy SDR remotely

######################################################

Server version: 0.5.2-unknown
Server UUID: 0249ece2-0333-172a-8567-059a007f0101
Launching the server... tcp://[::]:55132
Server bound to [::]:55132
Launching discovery server...
Connecting to DNS-SD daemon...
[INFO] Avahi version: avahi 0.8
[INFO] Avahi hostname: openwebrxbrugherio
[INFO] Avahi domain: local
[INFO] Avahi FQDN: openwebrxbrugherio.local
[INFO] avahi_entry_group_add_service(openwebrxbrugherio._soapy._tcp)
Press Ctrl+C to stop the server
SoapyServerListener::accept([fe80::10b1:c6c8:5ac8:b0%3]:50966)
SoapyServerListener::accept([::ffff:172.30.2.18]:50967)
[INFO] [UHD] linux; GNU C++ version 10.2.0; Boost_107100; UHD_3.15.0.0-4
usb_claim_interface error -6
Found Rafael Micro R820T tuner
SoapyServerListener::close()
SoapyServerListener::close()
SoapyServerListener::accept([fe80::10b1:c6c8:5ac8:b0%3]:50969)
SoapyServerListener::accept([fe80::10b1:c6c8:5ac8:b0%3]:50970)
SoapyServerListener::close()
SoapyServerListener::accept([fe80::10b1:c6c8:5ac8:b0%3]:50971)
SoapyServerListener::accept([fe80::10b1:c6c8:5ac8:b0%3]:50972)
SoapyServerListener::close()
SoapyServerListener::close()
SoapyServerListener::accept([fe80::10b1:c6c8:5ac8:b0%3]:50973)
SoapyServerListener::close()
SoapyServerListener::accept([fe80::10b1:c6c8:5ac8:b0%3]:50974)
terminate called after throwing an instance of 'char const*'
Aborted
root@raspberrypi:/home/pi#

this happened when I search the device in CUBICSDR

from soapyremote.

up

from soapyremote.

There is no (date) sorting in the issues, a bump won't do anything but annoy people.

We can't reproduce and need more info: where does that throw of a string (e.g. throw "the error string";) originate? It's not SoapyRemote, all throws are std::runtime_error here.

from soapyremote.