Error probing device: map::at

[jazzkutya]

SoapySDR 0.7.1, SoapySDRPlay 0.2.0 on Ubuntu 14.04 lts, x86-64. I get "Error probing device: map::at" with SoapySDRUtil --probe every time, I can't use Soapy at all.

after uncommenting try and catch @guruofquality mentioned in #50

Probe device 
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at
Aborted (core dumped)

despite what it says about a core dump, I do not have a core dump file because ubuntu. I will post it if I find it or succeed in producing it.

(gdb) run --probe
Starting program: /usr/local/bin/SoapySDRUtil --probe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device 
[New Thread 0x7ffff3e03700 (LWP 25327)]
[New Thread 0x7ffff3602700 (LWP 25328)]
[Thread 0x7ffff3e03700 (LWP 25327) exited]
[New Thread 0x7ffff3e03700 (LWP 25329)]
[Thread 0x7ffff3e03700 (LWP 25329) exited]
[Thread 0x7ffff3602700 (LWP 25328) exited]
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at

Program received signal SIGABRT, Aborted.
0x00007ffff6fbdc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff6fbdc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff6fc1028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff77e4535 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff77e26d6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff77e2703 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff77e26c7 in std::rethrow_exception(std::__exception_ptr::exception_ptr) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff7b6ba97 in std::__basic_future<SoapySDR::Device*>::_M_get_result (this=0x7fffffffd6b0) at /usr/include/c++/4.8/future:598
#7  0x00007ffff7b683cc in std::shared_future<SoapySDR::Device*>::get (this=0x7fffffffd6b0) at /usr/include/c++/4.8/future:804
#8  0x00007ffff7b5d90f in SoapySDR::Device::make (inputArgs=...) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/lib/Factory.cpp:192
#9  0x00007ffff7b5db56 in SoapySDR::Device::make (args=...) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/lib/Factory.cpp:201
#10 0x0000000000413571 in probeDevice (argStr=...) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/apps/SoapySDRUtil.cpp:200
#11 0x0000000000413a1c in main (argc=2, argv=0x7fffffffda08) at /home/vrm/sw/src/SoapySDR-soapy-sdr-0.7.1/apps/SoapySDRUtil.cpp:320
(gdb)

[guruofquality]

I think its throwing in the factory function. Since its in another thread, maybe there is no trace from that thread.

Can you put a few prints here, see if it gets to the constructor and how far it gets: https://github.com/pothosware/SoapySDRPlay/blob/master/Settings.cpp#L33

If that doesnt give you any prints, I would also try to check the find function: https://github.com/pothosware/SoapySDRPlay/blob/master/Registration.cpp#L34

[jazzkutya]

in the meantime, is SoapySDRPlay 0.2.0 compatible with SoapySDR 0.6.1? Gave it a try and it finds no device, and there is no "Error probing device: map::at"

[guruofquality]

in the meantime, is SoapySDRPlay 0.2.0 compatible with SoapySDR 0.6.1? Gave it a try and it finds no device, and there is no "Error probing device: map::at"

I cant see why 0.6.1 release would be any different in terms of compatibility. It should be fine assuming the support module for SDRPlay is properly installed.

[jazzkutya]

findSDRPlay entered, but SoapySDRPlay::SoapySDRPlay was not entered

[guruofquality]

Cool, did findSDRPlay throw the error, or did it complete and return nicely?

[jazzkutya]

|      85    std::cerr << "findSDRPlay is returning\n";
|      86 
|      87    return results;
|      88 }

well this print did happen

[guruofquality]

Quick question, are you using SoapySDRPlay release tag "soapy-sdrplay-0.2.0" or master branch (latest commit 31a3a361f77c9ac451f8722bb71df9c6a443614f)?

[jazzkutya]

|||    72         dev["label"] = lblstr;
|||    73         results.push_back(dev);
|||    74         std::cout << "in results: " << lblstr << "\n";
|||    75         _cachedResults[rspDevs[i].SerNo] = dev;

and this in findSDRPlay is not happenning

[jazzkutya]

started with release tag "soapy-sdrplay-0.2.0" then switched to master

[jazzkutya]

nDevs: 1 .devAvail: teh plot thickens

[guruofquality]

You said that the constructor was not entered, here is a map::at in the initializer list, so this could be the culprit if for some reason the serial was not passed in: https://github.com/pothosware/SoapySDRPlay/blob/master/Settings.cpp#L34

Also, if it helps, you can find which line in the factory throws, if that helps: https://github.com/pothosware/SoapySDR/blob/master/lib/Factory.cpp#L130

[jazzkutya]

are you sure RSP1 devices have serial numbers?

[guruofquality]

Not 100 % sure how the manufacturer does it. However, every handle gets a "serial" field written dev["serial"] = rspDevs[i].SerNo;, so this key should exist, even if it was an empty string. I'm curious if for some reason its not present.

[jazzkutya]

|| 56 if (rspDevs[i].devAvail) rspDevs[i].devAvail is 0 and this if block does not run. I have no idea why, since linrad runs fine. maybe i should try a reboot, but first let me tell the current installation of sdrplay api:

I had 1.8.x API installed and linrad running fine with the very old sdrplay extio dll ported to linux by me (uses the first api version). I wanted to keep the old api for linrad thus skpped sdrplay installer and only installed the .so file and made the symlinks manually. I put the include file in a non-system dir so I compile SoapySDRPlay with this: cmake .. -DCMAKE_INCLUDE_PATH=/home/vrm/sdrplay/include I removed the 1.8.x version of the .so file temporary (it's still not present in /usr/local/lib) to avoid problems while trying Soapy. Funny thing linrad still works. ldd libExtIO_SDRPlay.so verifies it's linking against /usr/local/lib/libmirsdrapi-rsp.so which is symlink to the 2.13 API. I still have a 32bit .so file in /usr/local/lib/i386-linux-gnu, but right now I tried removing it, ldconfig and no effect on linrad ans Soapy still gives this:

Probe device 
findSDRPlay entered
nDevs: 1
.devAvail: 0
findSDRPlay is returning
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at
Aborted (core dumped)

let me try a rebot now :)

[jazzkutya]

I've also verified that nothing comes out of SoapySDRPlay_getClaimedSerials() in findSDRPlay()

[jazzkutya]

after reboot devAvail is still 0, linrad still works. but I have many of this in dmesg: [ 164.413553] msi2500 3-1:1.0: Registered as swradio0 [ 164.413559] msi2500 3-1:1.0: SDR API is still slightly experimental and functionality changes may follow Maybe something in the kernel has the device, but linrad worked fine so I did not bother with it. Let me check the udev rules.

[jazzkutya]

rmmod msi2500;rmod msi001 fixes my problem

[jazzkutya]

So 'Error probing device: map::at' happens when findSDRPlay() does not find any available devices. Pretty poor error message if you ask me :)

[SDRplay]

I've just seen this thread. The following modules need to be blacklisted for the RSP1 to work correctly with SoapySDRPlay...

sdr_msi3101 msi001 msi2500

are you saying that there is a problem after you have blacklisted these modules?

[jazzkutya]

are you saying that there is a problem after you have blacklisted these modules?

I have not blacklisted them yet, and your ExtIO ported to linux works okay without blacklisting or rmmoding, that's why I haven't bothered with it yet. After rmmoding SoapySDRUtil --probe works fine, haven't tried any SoapySDR app yet. Also udev rules from 1.8.x are in place and I did not see any notes on blacklisting modules in you API package.

[guruofquality]

So 'Error probing device: map::at' happens when findSDRPlay() does not find any available devices. Pretty poor error message if you ask me :)

That would have been good to know that the map at error is only when you dont see any devices.

What are are being passed to --probe? For example --probe="driver=sdrplay".

My guess is that it doesnt find any devices, and tries to make it anyway. Even when you dont specify the driver=sdrplay, if sdrplay is the only module available it still probably tries to call its constructor. So its probably happening in the line suggested.

@jazzkutya can you confirm its that its this line: https://github.com/pothosware/SoapySDRPlay/blob/master/Settings.cpp#L34

If its that line, we can just throw an exception like "no sdrplays specified to be opened" and the bad error message goes away. :-)

[jazzkutya]

That would have been good to know that the map at error is only when you dont see any devices.

It's hard to notice this when the only device that could show up gives a cryptic error.

What are are being passed to --probe? For example --probe="driver=sdrplay".

nothing. SPEC in the man page is undocumented.

@jazzkutya can you confirm its that its this line: https://github.com/pothosware/SoapySDRPlay/blob/master/Settings.cpp#L34

If its that line, we can just throw an exception like "no sdrplays specified to be opened" and the bad error message goes away. :-)

How can I confirm this? I'm no good in C++ and don't know how to put a debug print on a chained method call or what it is called :)

[jazzkutya]

        34 SoapySDRPlay::SoapySDRPlay(const SoapySDR::Kwargs &args)
-       35 {
|       36     std::cerr << "SoapySDRPlay::SoapySDRPlay entered\n"; 
|       37     serNo=args.at("serial");
|       38     std::cerr << "SoapySDRPlay::SoapySDRPlay after serNo()\n";
|       39     // retreive hwVer and device index by API

result:

Probe device 
findSDRPlay entered
nDevs: 0
findSDRPlay is returning
SoapySDRPlay::SoapySDRPlay entered
terminate called after throwing an instance of 'std::out_of_range'
  what():  map::at
Aborted (core dumped)

Hopefully this confirms it. It also confirms I'm no good at C++ - turns out it's not chained method call but property initialisation :)

Could this be bug in SoapySDR?

[jazzkutya]

the API docs specifies that DevNm is a unique reference [identifying one device?], possibly implying this should be used instead of the serial number. I'm not sure this really means the constructor and findSDRPlay() should be changed to use DevNm.

[guruofquality]

I pushed what should be a fix to get a better error message: https://github.com/pothosware/SoapySDRPlay/commit/4e0c67d1e381e64597cfb5463965ef33f129ba35

the API docs specifies that DevNm is a unique reference [identifying one device?], possibly implying this should be used instead of the serial number. I'm not sure this really means the constructor and findSDRPlay() should be changed to use DevNm.

The device number is used once it finds a match for the serial number.

Most SoapySDR modules use serial numbers in the handle to support multiple devices of the same type. Device index numbers can be ambiguous and change. So in practice most device modules actually work the way this one does (at least USB ones do).

Hopefully this confirms it. It also confirms I'm no good at C++ - turns out it's not chained method call but property initialisation :) Could this be bug in SoapySDR?

Its an uncaught exception. I think you commented out the try/catch, so I guess this is normal. The constructor is actually throwing, and it probably should. Just with a better message.

[jazzkutya]

this is how it looks with your commit, and reenabled try/catch in SoapySDRUtil:

vrm@zivatar:~$ SoapySDRUtil --probe
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Probe device 
Error probing device: no sdrplay device found
vrm@zivatar:~$ 

many thanks for your time and commit!