SoapySDRPlay3 icon indicating copy to clipboard operation
SoapySDRPlay3 copied to clipboard

Segmentation fault when stopping playback With SigDigger develop branch

Open srs4511351 opened this issue 1 year ago • 51 comments

Computer: Raspberry Pi 4 Debian GNU/Linux 12 (bookworm) SDRplay RSP1A

develop branch It also involves another module https://github.com/BatchDrake/suscan/tree/develop SigDigger 0.3.0 custom build May 23 2023 (12.2.0) Using suscan version 0.3.0 (custom build on May 23 2023 at 01:25:58 (12.2.0)) Using sigutils version 0.3.0 (custom build on May 23 2023 at 20:42:30 (12.2.0))

When I press Run, it works normally. When I press the Run button to stop reception, SigDigger closes and Segmentation fault appears on the terminal.

The developer of SigDigger marked my issue as third party and asked me to open an issue here. See: https://github.com/BatchDrake/SigDigger/issues/216

Here is output from gdb

Thread 1 "SigDigger" received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=) at ./malloc/malloc.c:3362
3362	./malloc/malloc.c: No such file or directory.
(gdb) bt
#0  __GI___libc_free (mem=) at ./malloc/malloc.c:3362
#1  0x0000fffff7cabd50 in SoapySDRStrings_clear ()
    at /usr/local/lib/libSoapySDR.so.0.8-2
#2  0x0000fffff7cac294 in SoapySDRArgInfo_clear ()
    at /usr/local/lib/libSoapySDR.so.0.8-2
#3  0x0000fffff7e87c78 in suscan_source_destroy (source=0xaaaaac6d8a60)
    at /home/pi/suscan/analyzer/source.c:1635
#4  0x0000fffff7e6a6b4 in suscan_local_analyzer_dtor (ptr=0xaaaaac6d85b0)
    at /home/pi/suscan/analyzer/impl/local.c:904
#5  0x0000fffff7e61e98 in suscan_analyzer_destroy (self=0xaaaaac27b9f0)
    at /home/pi/suscan/analyzer/analyzer.c:671
#6  0x0000aaaaaac51ff8 in Suscan::Analyzer::~Analyzer() ()
#7  0x0000aaaaaac52028 in Suscan::Analyzer::~Analyzer() ()
#8  0x0000aaaaaab58608 in SigDigger::Application::orderedHalt() ()
#9  0x0000aaaaaab5b084 in SigDigger::Application::onAnalyzerHalted() ()
#10 0x0000fffff681a608 in  () at /lib/aarch64-linux-gnu/libQt5Core.so.5
#11 0x0000fffff680e6cc in QObject::event(QEvent*) ()
    at /lib/aarch64-linux-gnu/libQt5Core.so.5
#12 0x0000fffff74ac0a0 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
    () at /lib/aarch64-linux-gnu/libQt5Widgets.so.5
#13 0x0000fffff67dcd40 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
    () at /lib/aarch64-linux-gnu/libQt5Core.so.5
#14 0x0000fffff67e00a8 in QCoreApplicationPrivate::sendPostedEvents(QObject*, in--Type  for more, q to quit, c to continue without paging--c
t, QThreadData*) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
#15 0x0000fffff683f4e8 in  () at /lib/aarch64-linux-gnu/libQt5Core.so.5
#16 0x0000fffff4f5774c in g_main_context_dispatch ()
    at /lib/aarch64-linux-gnu/libglib-2.0.so.0
#17 0x0000fffff4f579e0 in  () at /lib/aarch64-linux-gnu/libglib-2.0.so.0
#18 0x0000fffff4f57a84 in g_main_context_iteration ()
    at /lib/aarch64-linux-gnu/libglib-2.0.so.0
#19 0x0000fffff683eaa8 in QEventDispatcherGlib::processEvents(QFlags<:processeventsflag>) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
#20 0x0000fffff67db258 in QEventLoop::exec(QFlags<:processeventsflag>) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
#21 0x0000fffff67e42dc in QCoreApplication::exec() ()
    at /lib/aarch64-linux-gnu/libQt5Core.so.5
#22 0x0000aaaaaab534f0 in main ()
(gdb) 

srs4511351 avatar Jun 07 '23 19:06 srs4511351

@srs4511351 - thanks for reporting this problem and including the output from gdb.

Looking at that output from gdb it seems to me that this issue might be similar to what was reported here: https://github.com/pothosware/SoapySDR/issues/361 - the comments there by @guruofquality and @zuckschwerdt might be helpful in understanding this problem.

Franco

fventuri avatar Jun 08 '23 02:06 fventuri

@fventuri So, is the problem in the pothosware base soapysdr release?

My crash only occurs with my SDRplay device and not with the HackRF or RTL-SDR, which may be why I was directed to SoapySDRPlay3.

After looking at https://github.com/pothosware/SoapySDR/issues/361 , do you think there is a usage error by the developer of the SigDigger application? I may not be fully understanding this issue. Should this problem be addressed by the SigDigger developer?

----Steve

srs4511351 avatar Jun 08 '23 06:06 srs4511351

@srs4511351 - as you can see in the stack trace you sent, the problem appears to be originated in the method SoapySDRStrings_clear(), which is part of the SoapySDR API.

This morning I also read the latest comments on the SigDigger issue you created and I think @BatchDrake was able to fix it in the develop branch. After you rebuild it and run it again, please let me know if you still have problems.

Franco

fventuri avatar Jun 08 '23 12:06 fventuri

After the rebuild, it still fails with a seg fault when playback is stopped.

He said Now it is done exactly as how @guruofquality describes

If you look at the , There is more discussion and debug data. I'm still not sure what software is at fault. This problem only occurs on the SDRplay device and not with the HackRF or the RTL-SDR. I do not have this problem with my other applications that use Soapy.

I think he is blaming the SDRplay library.

srs4511351 avatar Jun 08 '23 22:06 srs4511351

@srs4511351 - if you think this is a error with the SDRplay API, I would first try to reproduce it with a simple C program (possibly based on the example at the end of SDRplay API specification guide - https://www.sdrplay.com/docs/SDRplay_API_Specification_v3.07.pdf) to rule out any other possible cause, and then open a technical support case with them (https://www.sdrplay.com/help/) so they can look into this issue in more detail.

Franco

fventuri avatar Jun 09 '23 00:06 fventuri

The problem exists on all of my installed systems. My other applications work. I can't do much about it. If it is the SDRplay API, it's the same on all of my systems. If it is defective, it's the release.

The SigDigger developer seems to say that it is the SDRplay API. His current full release version works OK, but the develop branch does not.

I would hope that you could help him. I have a lot of your software installed that is specific to SDRplay, so you must know how to handle it. I am just trying to coordinate a fix for the SigDigger develop branch.

What can be done?

----Steve

srs4511351 avatar Jun 09 '23 04:06 srs4511351

@srs4511351 a minimal test would be roughly the contents of Registration.cpp, e.g. (edit: corrected wrong API)

#include <sdrplay_api.h>
int main()
{
    sdrplay_api_ErrT err;
    // Open API
    err = sdrplay_api_Open();
    if (err != sdrplay_api_Success) {
        throw std::runtime_error("sdrplay_api_Open() failed");
    }

    unsigned int nDevs = 0;
    sdrplay_api_LockDeviceApi();
    sdrplay_api_DeviceT rspDevs[SDRPLAY_MAX_DEVICES];
    sdrplay_api_GetDevices(&rspDevs[0], &nDevs, SDRPLAY_MAX_DEVICES); // <-- fault should be here
    sdrplay_api_UnlockDeviceApi();

    // Close API
    err = sdrplay_api_Close();
    if (err != sdrplay_api_Success) {
        throw std::runtime_error("sdrplay_api_Close() failed");
    }
}

You need to run with valgrind or watch with ASAN to see sdrplay_api_GetDevices() fail.

zuckschwerdt avatar Jun 09 '23 06:06 zuckschwerdt

I don't know how to do this. I haven't done any programming on this system.

If you could help me, I am interested in learning how. The API has been released years ago. It seems like someone would have looked into this by now.

----Steve

srs4511351 avatar Jun 09 '23 14:06 srs4511351

Save that content to a file playtest.c then run g++ -ggdb -fsanitize=undefined -fsanitize=address -fno-omit-frame-pointer -Wall -I/opt/local/include -I/usr/local/include -L/opt/local/lib -L/usr/local/lib -lsdrplay_api -o playtest playtest.cpp now you can run with ./playtest

Or to use valgrind compile with just g++ -ggdb -Wall -I/opt/local/include -I/usr/local/include -L/opt/local/lib -L/usr/local/lib -lsdrplay_api -o playtest playtest.cpp and run with valgrind --track-origins=yes playtest 2> errors.log

If you don't get a crash then some other factor is influencing wether sdrplay_api_GetDevices() breaks.

zuckschwerdt avatar Jun 09 '23 15:06 zuckschwerdt

@zuckschwerdt - thanks for your little test program; I made a couple of changes to just use plain C (see attached); I ran it with valgrind, and this is the output:

$ valgrind --track-origins=yes ./apitest 
==23919== Memcheck, a memory error detector
==23919== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==23919== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==23919== Command: ./apitest
==23919== 
==23919== 
==23919== HEAP SUMMARY:
==23919==     in use at exit: 0 bytes in 0 blocks
==23919==   total heap usage: 19 allocs, 19 frees, 82,774 bytes allocated
==23919== 
==23919== All heap blocks were freed -- no leaks are possible
==23919== 
==23919== For lists of detected and suppressed errors, rerun with: -s
==23919== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I then used the code from SoapySDR "Basic C API example" (https://github.com/pothosware/SoapySDR/wiki/C_API_Example#basic-c-api-example), removed most of it, just left the initial device discovery part with the call to SoapySDRDeviceEnumerate() (code attached), and ran it with valgrind:

$ valgrind --track-origins=yes ./soapytest 
==23986== Memcheck, a memory error detector
==23986== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==23986== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==23986== Command: ./soapytest
==23986== 
Found device #0: driver=sdrplay, label=SDRplay Dev0 RSPdx **********, serial=**********, 
Done
==23986== 
==23986== HEAP SUMMARY:
==23986==     in use at exit: 6,600 bytes in 16 blocks
==23986==   total heap usage: 119 allocs, 103 frees, 131,147 bytes allocated
==23986== 
==23986== LEAK SUMMARY:
==23986==    definitely lost: 0 bytes in 0 blocks
==23986==    indirectly lost: 0 bytes in 0 blocks
==23986==      possibly lost: 0 bytes in 0 blocks
==23986==    still reachable: 6,600 bytes in 16 blocks
==23986==         suppressed: 0 bytes in 0 blocks
==23986== Rerun with --leak-check=full to see details of leaked memory
==23986== 
==23986== For lists of detected and suppressed errors, rerun with: -s
==23986== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I ran it again with the additional options --leak-check=full --show-leak-kinds=all, and this is the output:

$ valgrind --track-origins=yes --leak-check=full --show-leak-kinds=all ./soapytest 
==23872== Memcheck, a memory error detector
==23872== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==23872== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==23872== Command: ./soapytest
==23872== 
Found device #0: driver=sdrplay, label=SDRplay Dev0 RSPdx **********, serial=**********, 
Done
==23872== 
==23872== HEAP SUMMARY:
==23872==     in use at exit: 6,600 bytes in 16 blocks
==23872==   total heap usage: 119 allocs, 103 frees, 131,147 bytes allocated
==23872== 
==23872== 60 bytes in 1 blocks are still reachable in loss record 1 of 7
==23872==    at 0x484182F: malloc (vg_replace_malloc.c:431)
==23872==    by 0x402468F: malloc (rtld-malloc.h:56)
==23872==    by 0x402468F: strdup (strdup.c:42)
==23872==    by 0x40089FB: _dl_map_object (dl-load.c:2186)
==23872==    by 0x400C62B: dl_open_worker_begin (dl-open.c:534)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400BDDF: dl_open_worker (dl-open.c:782)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400C1B3: _dl_open (dl-open.c:884)
==23872==    by 0x4F8A6D3: dlopen_doit (dlopen.c:56)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x4001678: _dl_catch_error (dl-catch.c:256)
==23872==    by 0x4F8A1B2: _dlerror_run (dlerror.c:138)
==23872== 
==23872== 60 bytes in 1 blocks are still reachable in loss record 2 of 7
==23872==    at 0x484182F: malloc (vg_replace_malloc.c:431)
==23872==    by 0x400BB50: UnknownInlinedFun (rtld-malloc.h:56)
==23872==    by 0x400BB50: _dl_new_object (dl-object.c:199)
==23872==    by 0x4006FEE: _dl_map_object_from_fd (dl-load.c:1063)
==23872==    by 0x4008AA8: _dl_map_object (dl-load.c:2253)
==23872==    by 0x400C62B: dl_open_worker_begin (dl-open.c:534)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400BDDF: dl_open_worker (dl-open.c:782)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400C1B3: _dl_open (dl-open.c:884)
==23872==    by 0x4F8A6D3: dlopen_doit (dlopen.c:56)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x4001678: _dl_catch_error (dl-catch.c:256)
==23872== 
==23872== 81 bytes in 3 blocks are still reachable in loss record 3 of 7
==23872==    at 0x484182F: malloc (vg_replace_malloc.c:431)
==23872==    by 0x402468F: malloc (rtld-malloc.h:56)
==23872==    by 0x402468F: strdup (strdup.c:42)
==23872==    by 0x40144A7: _dl_load_cache_lookup (dl-cache.c:515)
==23872==    by 0x4008D13: _dl_map_object (dl-load.c:2120)
==23872==    by 0x400282C: openaux (dl-deps.c:64)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x4002C87: _dl_map_object_deps (dl-deps.c:232)
==23872==    by 0x400C694: dl_open_worker_begin (dl-open.c:592)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400BDDF: dl_open_worker (dl-open.c:782)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400C1B3: _dl_open (dl-open.c:884)
==23872== 
==23872== 81 bytes in 3 blocks are still reachable in loss record 4 of 7
==23872==    at 0x484182F: malloc (vg_replace_malloc.c:431)
==23872==    by 0x400BB50: UnknownInlinedFun (rtld-malloc.h:56)
==23872==    by 0x400BB50: _dl_new_object (dl-object.c:199)
==23872==    by 0x4006FEE: _dl_map_object_from_fd (dl-load.c:1063)
==23872==    by 0x4008AA8: _dl_map_object (dl-load.c:2253)
==23872==    by 0x400282C: openaux (dl-deps.c:64)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x4002C87: _dl_map_object_deps (dl-deps.c:232)
==23872==    by 0x400C694: dl_open_worker_begin (dl-open.c:592)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400BDDF: dl_open_worker (dl-open.c:782)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400C1B3: _dl_open (dl-open.c:884)
==23872== 
==23872== 1,276 bytes in 1 blocks are still reachable in loss record 5 of 7
==23872==    at 0x484682C: calloc (vg_replace_malloc.c:1554)
==23872==    by 0x400B86D: UnknownInlinedFun (rtld-malloc.h:44)
==23872==    by 0x400B86D: _dl_new_object (dl-object.c:92)
==23872==    by 0x4006FEE: _dl_map_object_from_fd (dl-load.c:1063)
==23872==    by 0x4008AA8: _dl_map_object (dl-load.c:2253)
==23872==    by 0x400C62B: dl_open_worker_begin (dl-open.c:534)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400BDDF: dl_open_worker (dl-open.c:782)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400C1B3: _dl_open (dl-open.c:884)
==23872==    by 0x4F8A6D3: dlopen_doit (dlopen.c:56)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x4001678: _dl_catch_error (dl-catch.c:256)
==23872== 
==23872== 1,344 bytes in 4 blocks are still reachable in loss record 6 of 7
==23872==    at 0x484682C: calloc (vg_replace_malloc.c:1554)
==23872==    by 0x401375F: UnknownInlinedFun (rtld-malloc.h:44)
==23872==    by 0x401375F: _dl_check_map_versions (dl-version.c:280)
==23872==    by 0x400C6DA: dl_open_worker_begin (dl-open.c:600)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400BDDF: dl_open_worker (dl-open.c:782)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400C1B3: _dl_open (dl-open.c:884)
==23872==    by 0x4F8A6D3: dlopen_doit (dlopen.c:56)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x4001678: _dl_catch_error (dl-catch.c:256)
==23872==    by 0x4F8A1B2: _dlerror_run (dlerror.c:138)
==23872==    by 0x4F8A78E: UnknownInlinedFun (dlopen.c:71)
==23872==    by 0x4F8A78E: dlopen@@GLIBC_2.34 (dlopen.c:81)
==23872== 
==23872== 3,698 bytes in 3 blocks are still reachable in loss record 7 of 7
==23872==    at 0x484682C: calloc (vg_replace_malloc.c:1554)
==23872==    by 0x400B86D: UnknownInlinedFun (rtld-malloc.h:44)
==23872==    by 0x400B86D: _dl_new_object (dl-object.c:92)
==23872==    by 0x4006FEE: _dl_map_object_from_fd (dl-load.c:1063)
==23872==    by 0x4008AA8: _dl_map_object (dl-load.c:2253)
==23872==    by 0x400282C: openaux (dl-deps.c:64)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x4002C87: _dl_map_object_deps (dl-deps.c:232)
==23872==    by 0x400C694: dl_open_worker_begin (dl-open.c:592)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400BDDF: dl_open_worker (dl-open.c:782)
==23872==    by 0x4001522: _dl_catch_exception (dl-catch.c:237)
==23872==    by 0x400C1B3: _dl_open (dl-open.c:884)
==23872== 
==23872== LEAK SUMMARY:
==23872==    definitely lost: 0 bytes in 0 blocks
==23872==    indirectly lost: 0 bytes in 0 blocks
==23872==      possibly lost: 0 bytes in 0 blocks
==23872==    still reachable: 6,600 bytes in 16 blocks
==23872==         suppressed: 0 bytes in 0 blocks
==23872== 
==23872== For lists of detected and suppressed errors, rerun with: -s
==23872== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

My tests were run on my x86_64 Linux desktop running Fedora Core and SDRplay API version 3.07.

@srs4511351 - Steve, I saw in your initial message that you are running the application that crashes on a Raspberry Pi with 64bit ARM (aarch64), so your shared library for the SDRplay API is different from mine. Since they are different, it is also possible that there's a bug in your version of that shared library that is not in the one for x86_64 that I am running here.

Finally since the SDRplay API library is proprietary of SDRplay and it is not open source, there's only so much that I/we can do if the issue turns out to be in one of the functions of the API itself, like sdrplay_api_GetDevices(). In that case I think the only way to get it resolved is to open a technical support case with SDRplay.

Franco

apitest.zip soapytest.zip

fventuri avatar Jun 10 '23 00:06 fventuri

@zuckschwerdt I would like to try this on my Raspbery Pi, but I was unable to compile your code. As instructed, I saved as playtest.c The compile command referred to playtest.cpp

Running the compile with the file named playtest.cpp:

playtest.cpp: In function ‘int main()’:
playtest.cpp:8:20: error: ‘runtime_error’ is not a member of ‘std’
    8 |         throw std::runtime_error("sdrplay_api_Open() failed");
      |                    ^~~~~~~~~~~~~
playtest.cpp:20:20: error: ‘runtime_error’ is not a member of ‘std’
   20 |         throw std::runtime_error("sdrplay_api_Close() failed");
      |                    ^~~~~~~~~~~~~

@fventuri Not really knowing how to compile your code, I tried to compile apitest.c with the @zuckschwerdt command:

g++ -ggdb -fsanitize=undefined -fsanitize=address -fno-omit-frame-pointer -Wall -I/opt/local/include -I/usr/local/include -L/opt/local/lib -L/usr/local/lib -lsdrplay_api -o apitest apitest.c

I got

/usr/bin/ld: /tmp/ccBSyQhH.o: in function `main':
/home/pi/apitest/apitest.c:9: undefined reference to `sdrplay_api_Open'
/usr/bin/ld: /home/pi/apitest/apitest.c:16: undefined reference to `sdrplay_api_LockDeviceApi'
/usr/bin/ld: /home/pi/apitest/apitest.c:18: undefined reference to `sdrplay_api_GetDevices'
/usr/bin/ld: /home/pi/apitest/apitest.c:22: undefined reference to `sdrplay_api_UnlockDeviceApi'
/usr/bin/ld: /home/pi/apitest/apitest.c:25: undefined reference to `sdrplay_api_Close'
collect2: error: ld returned 1 exit status

----Steve

srs4511351 avatar Jun 10 '23 03:06 srs4511351

@fventuri I wasn't sure if the C++ runtime is contributing to this strangeness. I don't see any fault. The code is just a guess based on what is seen in https://github.com/BatchDrake/SigDigger/issues/216#issuecomment-1583318432 i.e.

==2340== Source and destination overlap in memcpy(0xc49f570, 0x487e010, 88887341568)
==2340==    by 0x1E517C6F: memcpy (string3.h:53)
==2340==    by 0x1E517C6F: sdrplay_api_GetDevices (sdrplay_api.cpp:321)

I would suspect an unterminated string that only gets out of bounds because valgrind filled the memory with guard values or such heisenbug effects?

zuckschwerdt avatar Jun 10 '23 09:06 zuckschwerdt

@srs4511351 sorry, add a first line of #include <stdexcept>

zuckschwerdt avatar Jun 10 '23 09:06 zuckschwerdt

@zuckschwerdt We may be getting further, as the errors are now similar to the errors from the code from @fventuri :

/usr/bin/ld: /tmp/ccjnLWVK.o: in function `main':
/home/pi/playtest/playtest.cpp:7: undefined reference to `sdrplay_api_Open'
/usr/bin/ld: /home/pi/playtest/playtest.cpp:13: undefined reference to `sdrplay_api_LockDeviceApi'
/usr/bin/ld: /home/pi/playtest/playtest.cpp:15: undefined reference to `sdrplay_api_GetDevices'
/usr/bin/ld: /home/pi/playtest/playtest.cpp:16: undefined reference to `sdrplay_api_UnlockDeviceApi'
/usr/bin/ld: /home/pi/playtest/playtest.cpp:19: undefined reference to `sdrplay_api_Close'
collect2: error: ld returned 1 exit status

----Steve

srs4511351 avatar Jun 10 '23 15:06 srs4511351

@zuckschwerdt - good point about the C++ runtime

I changed the apitest program back to the original, and I wrote a simple program in C++ (soapytest) based on the SoapySDR C++ example code (https://github.com/pothosware/SoapySDR/wiki/Cpp_API_Example).

I also created a simple Makefile to make it easier to build the tests and run them with valgrind

@srs4511351 - Steve, please extract these content of the attached zip to an empty directory on your Raspberry Pi, and then run:

make

make run-apitest
make valgrind-apitest

make run-soapytest
make valgrind-soapytest

make run-soapytest-doublefree
make valgrind-soapytest-doublefree

Here on my Linux x86_64 all three tests (including the one where the program calls results.clear() twice) run without any error; for instance

$ make valgrind-soapytest-doublefree

valgrind --track-origins=yes ./soapytest-doublefree
==5426== Memcheck, a memory error detector
==5426== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==5426== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==5426== Command: ./soapytest-doublefree
==5426== 
==5426==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==5426== 
==5426== HEAP SUMMARY:
==5426==     in use at exit: 0 bytes in 0 blocks
==5426==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==5426== 
==5426== All heap blocks were freed -- no leaks are possible
==5426== 
==5426== For lists of detected and suppressed errors, rerun with: -s
==5426== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Franco

valigrind-tests.zip

fventuri avatar Jun 10 '23 17:06 fventuri

This may be insightful, the problem occurs after a null size allocation: https://github.com/BatchDrake/SigDigger/issues/216#issuecomment-1585717929

BatchDrake avatar Jun 10 '23 17:06 BatchDrake

I’m up to 30 times starting and stopping playback with an RSP1a on SigDigger dev branch + git pull on soapysdrplay3 today + 22.04 x86_64 at the moment (rebuilt it again today) and unfortunately/fortunately cannot get this to occur.

alphafox02 avatar Jun 10 '23 18:06 alphafox02

Above talked about test ran on my end using the setup I just talked about

dragon@dragon:~/Downloads$ make valgrind-soapytest-doublefree 
valgrind --track-origins=yes ./soapytest-doublefree
==322568== Memcheck, a memory error detector
==322568== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==322568== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==322568== Command: ./soapytest-doublefree
==322568== 
==322568==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==322568== 
==322568== Process terminating with default action of signal 11 (SIGSEGV)
==322568==  General Protection Fault
==322568==    at 0x5CC2F42: __pthread_once_slow (pthread_once.c:114)
==322568==    by 0x5D91A52: __rpc_thread_variables (rpc_thread.c:59)
==322568==    by 0x5DE4D8C: free_mem (in /usr/lib/x86_64-linux-gnu/libc.so.6)
==322568==    by 0x5DE48C1: __libc_freeres (in /usr/lib/x86_64-linux-gnu/libc.so.6)
==322568==    by 0x483F1B2: _vgnU_freeres (in /usr/libexec/valgrind/vgpreload_core-amd64-linux.so)
==322568==    by 0x4A6F3DF: ???
==322568==    by 0x49652B6: __sanitizer::Die() (sanitizer_termination.cpp:59)
==322568==    by 0x493B398: __asan::AsanCheckDynamicRTPrereqs() (asan_linux.cpp:181)
==322568==    by 0x4947544: __asan::AsanInitInternal() [clone .part.0] (asan_rtl.cpp:420)
==322568==    by 0x40065BD: _dl_init (dl-init.c:102)
==322568==    by 0x40202E9: ??? (in /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
==322568== 
==322568== HEAP SUMMARY:
==322568==     in use at exit: 0 bytes in 0 blocks
==322568==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==322568== 
==322568== All heap blocks were freed -- no leaks are possible
==322568== 
==322568== For lists of detected and suppressed errors, rerun with: -s
==322568== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
make: *** [Makefile:34: valgrind-soapytest-doublefree] Error 1

alphafox02 avatar Jun 10 '23 18:06 alphafox02

Here is the terminal output from all of the commands that you specify. It looks like they have been executed after each compile. Are the make errors a big problem?

dietpi@DietPi:~/valigrind-tests$ ls
apitest.cpp  Makefile  soapytest.cpp
dietpi@DietPi:~/valigrind-tests$ make
g++ -ggdb -fsanitize=undefined -fsanitize=address -fno-omit-frame-pointer -Wall apitest.cpp -o apitest -lsdrplay_api
g++ -ggdb -fsanitize=undefined -fsanitize=address -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest -lSoapySDR
g++ -DDOUBLE_FREE -ggdb -fsanitize=undefined -fsanitize=address -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest-doublefree -lSoapySDR
dietpi@DietPi:~/valigrind-tests$ make run-apitest
./apitest
dietpi@DietPi:~/valigrind-tests$ make valgrind-apitest
valgrind --track-origins=yes ./apitest
==2232== Memcheck, a memory error detector
==2232== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2232== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==2232== Command: ./apitest
==2232== 
==2232==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==2232== 
==2232== HEAP SUMMARY:
==2232==     in use at exit: 0 bytes in 0 blocks
==2232==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2232== 
==2232== All heap blocks were freed -- no leaks are possible
==2232== 
==2232== For lists of detected and suppressed errors, rerun with: -s
==2232== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
make: *** [Makefile:28: valgrind-apitest] Error 1
dietpi@DietPi:~/valigrind-tests$ make run-soapytest
./soapytest
Found device #0: device = HackRF One
driver = hackrf
label = HackRF One #0 17c467dc315234c3
part_id = a000cb3c0054475f
serial = 000000000000000017c467dc315234c3
version = 2023.01.1

Found device #1: driver = sdrplay
label = SDRplay Dev0 RSP1A 19110C0797
serial = 19110C0797

Done
dietpi@DietPi:~/valigrind-tests$ make valgrind-soapytest
valgrind --track-origins=yes ./soapytest
==2252== Memcheck, a memory error detector
==2252== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2252== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==2252== Command: ./soapytest
==2252== 
==2252==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==2252== 
==2252== HEAP SUMMARY:
==2252==     in use at exit: 0 bytes in 0 blocks
==2252==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2252== 
==2252== All heap blocks were freed -- no leaks are possible
==2252== 
==2252== For lists of detected and suppressed errors, rerun with: -s
==2252== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
make: *** [Makefile:31: valgrind-soapytest] Error 1
dietpi@DietPi:~/valigrind-tests$ make run-soapytest-doublefree
./soapytest-doublefree
Found device #0: device = HackRF One
driver = hackrf
label = HackRF One #0 17c467dc315234c3
part_id = a000cb3c0054475f
serial = 000000000000000017c467dc315234c3
version = 2023.01.1

Found device #1: driver = sdrplay
label = SDRplay Dev0 RSP1A 19110C0797
serial = 19110C0797

Calling clear() again
Done
dietpi@DietPi:~/valigrind-tests$ make valgrind-soapytest-doublefree
valgrind --track-origins=yes ./soapytest-doublefree
==2263== Memcheck, a memory error detector
==2263== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2263== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==2263== Command: ./soapytest-doublefree
==2263== 
==2263==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==2263== 
==2263== HEAP SUMMARY:
==2263==     in use at exit: 0 bytes in 0 blocks
==2263==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2263== 
==2263== All heap blocks were freed -- no leaks are possible
==2263== 
==2263== For lists of detected and suppressed errors, rerun with: -s
==2263== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
make: *** [Makefile:34: valgrind-soapytest-doublefree] Error 1
dietpi@DietPi:~/valigrind-tests$ 

----Steve

srs4511351 avatar Jun 10 '23 20:06 srs4511351

@srs4511351 and @alphafox02 - thanks for running the tests.

Steve's output looks identical to mine - I did notice that with valgrind for some reason I don't see the lines written to stdout, and it returns 1 (instead of 0); I am not sure why though, since I am fairly new to valgrind.

Also I saw that @BatchDrake found a problem with the method SoapySDRDevice_getSettingInfo(), which it is currently not called by my test program soapytest, so I'll add that and I'll post a new zip file with the code and the Makefile shortly.

Franco

fventuri avatar Jun 10 '23 20:06 fventuri

I found out the reason of the valgrind tests all returning error (exit status=1) and not printing any output: apparently the ASan runtime used by valgrind is not compatible with the compile option -fsanitize=address, so I removed this compile option, and now I see the crash in the case with the double free (and valgrind complaining a lot, of course).

I also added a call to getSettingInfo() that hopefully should then call SoapySDRDevice_getSettingIfo(), so we can see what happens in this case.

@srs4511351 @alphafox02 - please remove the directory with the previous tests, create a new directory, and unzip the contents of the attached file in that directory. After that, please run these commands:

make

make run-apitest
make valgrind-apitest

make run-soapytest
make valgrind-soapytest

Franco

valgrind-tests.zip

fventuri avatar Jun 10 '23 21:06 fventuri

Re-did tests, will also run them on 22.04 aarch64 with my Pi later. This is on x86_64. This is with the RSPDX plugged in, I can also grab the RSP1A.

make
g++ -ggdb -fsanitize=undefined -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest -lSoapySDR
g++ -DDOUBLE_FREE -ggdb -fsanitize=undefined -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest-doublefree -lSoapySDR
dragon@dragon:~/Downloads$ make run-apitest 
./apitest
dragon@dragon:~/Downloads$ make valgrind-apitest 
valgrind --track-origins=yes ./apitest
==323416== Memcheck, a memory error detector
==323416== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==323416== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==323416== Command: ./apitest
==323416== 
==323416==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==323416== 
==323416== Process terminating with default action of signal 11 (SIGSEGV)
==323416==  General Protection Fault
==323416==    at 0x5F07F42: __pthread_once_slow (pthread_once.c:114)
==323416==    by 0x5FD6A52: __rpc_thread_variables (rpc_thread.c:59)
==323416==    by 0x6029D8C: free_mem (in /usr/lib/x86_64-linux-gnu/libc.so.6)
==323416==    by 0x60298C1: __libc_freeres (in /usr/lib/x86_64-linux-gnu/libc.so.6)
==323416==    by 0x483F1B2: _vgnU_freeres (in /usr/libexec/valgrind/vgpreload_core-amd64-linux.so)
==323416==    by 0x4A6F3DF: ???
==323416==    by 0x49652B6: __sanitizer::Die() (sanitizer_termination.cpp:59)
==323416==    by 0x493B398: __asan::AsanCheckDynamicRTPrereqs() (asan_linux.cpp:181)
==323416==    by 0x4947544: __asan::AsanInitInternal() [clone .part.0] (asan_rtl.cpp:420)
==323416==    by 0x40065BD: _dl_init (dl-init.c:102)
==323416==    by 0x40202E9: ??? (in /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2)
==323416== 
==323416== HEAP SUMMARY:
==323416==     in use at exit: 0 bytes in 0 blocks
==323416==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==323416== 
==323416== All heap blocks were freed -- no leaks are possible
==323416== 
==323416== For lists of detected and suppressed errors, rerun with: -s
==323416== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
make: *** [Makefile:29: valgrind-apitest] Error 1
dragon@dragon:~/Downloads$ make run-soapytest
./soapytest
[WARNING] SoapyVOLKConverters: no VOLK config file found. Run volk_profile for best performance.                                                                            
Found device #0: driver = sdrplay
label = SDRplay Dev0 RSPdx 2003072543
serial = 2003072543

[INFO] devIdx: 0
[INFO] SerNo: 2003072543
[INFO] hwVer: 4
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
Setting #0:   key=rfgain_sel   name=RF Gain Select   value=4
Setting #1:   key=iqcorr_ctrl   name=IQ Correction   value=true
Setting #2:   key=agc_setpoint   name=AGC Setpoint   value=-30
Setting #3:   key=biasT_ctrl   name=BiasT Enable   value=true
Setting #4:   key=rfnotch_ctrl   name=RfNotch Enable   value=true
Setting #5:   key=dabnotch_ctrl   name=DabNotch Enable   value=true
Done
dragon@dragon:~/Downloads$ make valgrind-soapytest
valgrind --track-origins=yes ./soapytest
==323460== Memcheck, a memory error detector
==323460== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==323460== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==323460== Command: ./soapytest
==323460== 
[WARNING] SoapyVOLKConverters: no VOLK config file found. Run volk_profile for best performance.                                                                            
Found device #0: driver = sdrplay
label = SDRplay Dev0 RSPdx 2003072543
serial = 2003072543

[INFO] devIdx: 0
[INFO] SerNo: 2003072543
[INFO] hwVer: 4
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
Setting #0:   key=rfgain_sel   name=RF Gain Select   value=4
Setting #1:   key=iqcorr_ctrl   name=IQ Correction   value=true
Setting #2:   key=agc_setpoint   name=AGC Setpoint   value=-30
Setting #3:   key=biasT_ctrl   name=BiasT Enable   value=true
Setting #4:   key=rfnotch_ctrl   name=RfNotch Enable   value=true
Setting #5:   key=dabnotch_ctrl   name=DabNotch Enable   value=true
Done
==323460== 
==323460== HEAP SUMMARY:
==323460==     in use at exit: 106,201 bytes in 249 blocks
==323460==   total heap usage: 13,034 allocs, 12,785 frees, 1,721,027 bytes allocated
==323460== 
==323460== LEAK SUMMARY:
==323460==    definitely lost: 0 bytes in 0 blocks
==323460==    indirectly lost: 0 bytes in 0 blocks
==323460==      possibly lost: 0 bytes in 0 blocks
==323460==    still reachable: 106,201 bytes in 249 blocks
==323460==         suppressed: 0 bytes in 0 blocks
==323460== Rerun with --leak-check=full to see details of leaked memory
==323460== 
==323460== For lists of detected and suppressed errors, rerun with: -s
==323460== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
dragon@dragon:~/Downloads$ 

alphafox02 avatar Jun 10 '23 23:06 alphafox02

@alphafox02 - I noticed that the output of the make command at the very beginning of your message shows that it rebuilt only two executables (soapytest and soapytest-doublefree), but not apitest; perhaps you have an old version of that executable still laying around in that directory.

Could you please run make clean first, then make again, and then re-run just the two cases for apitest, i.e.:

make clean

make

make run-apitest
make valgrind-apitest

If these two apitest commands run without errors on x86_64, then I am very interested to see what happens on your Raspberry Pi running ARM64 (aarch64) to see if perhaps you are able to reproduce the problem with SoapySDRDevice_getSettingInfo() there.

Franco

fventuri avatar Jun 11 '23 01:06 fventuri

Edit: Eek! I just realized these are the old tests! New test coming!

Here are my Raspberry Pi tests

dietpi@DietPi:~/valigrind-tests$ make
g++ -ggdb -fsanitize=undefined -fsanitize=address -fno-omit-frame-pointer -Wall apitest.cpp -o apitest -lsdrplay_api
g++ -ggdb -fsanitize=undefined -fsanitize=address -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest -lSoapySDR
g++ -DDOUBLE_FREE -ggdb -fsanitize=undefined -fsanitize=address -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest-doublefree -lSoapySDR
dietpi@DietPi:~/valigrind-tests$ make run-apitest
./apitest
dietpi@DietPi:~/valigrind-tests$ make valgrind-apitest
valgrind --track-origins=yes ./apitest
==3215== Memcheck, a memory error detector
==3215== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3215== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3215== Command: ./apitest
==3215== 
==3215==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==3215== 
==3215== HEAP SUMMARY:
==3215==     in use at exit: 0 bytes in 0 blocks
==3215==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==3215== 
==3215== All heap blocks were freed -- no leaks are possible
==3215== 
==3215== For lists of detected and suppressed errors, rerun with: -s
==3215== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
make: *** [Makefile:28: valgrind-apitest] Error 1
dietpi@DietPi:~/valigrind-tests$ make run-soapytest
./soapytest
Found device #0: device = HackRF One
driver = hackrf
label = HackRF One #0 17c467dc315234c3
part_id = a000cb3c0054475f
serial = 000000000000000017c467dc315234c3
version = 2023.01.1

Found device #1: driver = sdrplay
label = SDRplay Dev0 RSP1A 19110C0797
serial = 19110C0797

Done
dietpi@DietPi:~/valigrind-tests$ make valgrind-soapytest
valgrind --track-origins=yes ./soapytest
==3229== Memcheck, a memory error detector
==3229== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3229== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3229== Command: ./soapytest
==3229== 
==3229==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
==3229== 
==3229== HEAP SUMMARY:
==3229==     in use at exit: 0 bytes in 0 blocks
==3229==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==3229== 
==3229== All heap blocks were freed -- no leaks are possible
==3229== 
==3229== For lists of detected and suppressed errors, rerun with: -s
==3229== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
make: *** [Makefile:31: valgrind-soapytest] Error 1
dietpi@DietPi:~/valigrind-tests$ 

----Steve

srs4511351 avatar Jun 11 '23 02:06 srs4511351

@srs4511351 - I noticed that the output of the make command at the very beginning of your message still shows the compile option -fsanitize=address; perhaps you are using an old version of the Makefile, not the one in the zip file I attached to this message earlier https://github.com/pothosware/SoapySDRPlay3/issues/71#issuecomment-1585820978

Franco

fventuri avatar Jun 11 '23 02:06 fventuri

Yes, I just noticed that they were the old tests, sorry. Here are the new tests

dietpi@DietPi:~/valgrind-tests$ make
g++ -ggdb -fsanitize=undefined -fno-omit-frame-pointer -Wall apitest.cpp -o apitest -lsdrplay_api
g++ -ggdb -fsanitize=undefined -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest -lSoapySDR
g++ -DDOUBLE_FREE -ggdb -fsanitize=undefined -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest-doublefree -lSoapySDR
dietpi@DietPi:~/valgrind-tests$ make run-apitest
./apitest
dietpi@DietPi:~/valgrind-tests$ make valgrind-apitest
valgrind --track-origins=yes ./apitest
==3933== Memcheck, a memory error detector
==3933== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3933== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3933== Command: ./apitest
==3933== 
==3933== 
==3933== HEAP SUMMARY:
==3933==     in use at exit: 0 bytes in 0 blocks
==3933==   total heap usage: 20 allocs, 20 frees, 80,919 bytes allocated
==3933== 
==3933== All heap blocks were freed -- no leaks are possible
==3933== 
==3933== For lists of detected and suppressed errors, rerun with: -s
==3933== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
dietpi@DietPi:~/valgrind-tests$ make run-soapytest
./soapytest
Found device #0: driver = sdrplay
label = SDRplay Dev0 RSP1A 19110C0797
serial = 19110C0797

[INFO] devIdx: 0
[INFO] SerNo: 19110C0797
[INFO] hwVer: 255
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
Setting #0:   key=gain_ctrl_mode   name=Gain Control Mode   value=LEGACY
Setting #1:   key=rfgain_sel   name=RF Gain Select   value=4
Setting #2:   key=iqcorr_ctrl   name=IQ Correction   value=true
Setting #3:   key=agc_setpoint   name=AGC Setpoint   value=-30
Setting #4:   key=biasT_ctrl   name=BiasT Enable   value=true
Setting #5:   key=rfnotch_ctrl   name=RfNotch Enable   value=true
Setting #6:   key=dabnotch_ctrl   name=DabNotch Enable   value=true
Done
dietpi@DietPi:~/valgrind-tests$ make valgrind-soapytest
valgrind --track-origins=yes ./soapytest
==3948== Memcheck, a memory error detector
==3948== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3948== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3948== Command: ./soapytest
==3948== 
Found device #0: driver = sdrplay
label = SDRplay Dev0 RSP1A 19110C0797
serial = 19110C0797

[INFO] devIdx: 0
[INFO] SerNo: 19110C0797
[INFO] hwVer: 255
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
Setting #0:   key=gain_ctrl_mode   name=Gain Control Mode   value=LEGACY
Setting #1:   key=rfgain_sel   name=RF Gain Select   value=4
Setting #2:   key=iqcorr_ctrl   name=IQ Correction   value=true
Setting #3:   key=agc_setpoint   name=AGC Setpoint   value=-30
Setting #4:   key=biasT_ctrl   name=BiasT Enable   value=true
Setting #5:   key=rfnotch_ctrl   name=RfNotch Enable   value=true
Setting #6:   key=dabnotch_ctrl   name=DabNotch Enable   value=true
Done
==3948== 
==3948== HEAP SUMMARY:
==3948==     in use at exit: 16,013 bytes in 42 blocks
==3948==   total heap usage: 306 allocs, 264 frees, 162,918 bytes allocated
==3948== 
==3948== LEAK SUMMARY:
==3948==    definitely lost: 24 bytes in 1 blocks
==3948==    indirectly lost: 0 bytes in 0 blocks
==3948==      possibly lost: 0 bytes in 0 blocks
==3948==    still reachable: 15,989 bytes in 41 blocks
==3948==         suppressed: 0 bytes in 0 blocks
==3948== Rerun with --leak-check=full to see details of leaked memory
==3948== 
==3948== For lists of detected and suppressed errors, rerun with: -s
==3948== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
dietpi@DietPi:~/valgrind-tests$ 

----Steve

srs4511351 avatar Jun 11 '23 02:06 srs4511351

Ran again after a make clean on x86_64

dragon@dragon:~/Downloads$ make
g++ -ggdb -fsanitize=undefined -fno-omit-frame-pointer -Wall apitest.cpp -o apitest -lsdrplay_api
g++ -ggdb -fsanitize=undefined -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest -lSoapySDR
g++ -DDOUBLE_FREE -ggdb -fsanitize=undefined -fno-omit-frame-pointer -Wall soapytest.cpp -o soapytest-doublefree -lSoapySDR
dragon@dragon:~/Downloads$ make run-apitest 
./apitest
dragon@dragon:~/Downloads$ make valgrind-apitest 
valgrind --track-origins=yes ./apitest
==325617== Memcheck, a memory error detector
==325617== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==325617== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==325617== Command: ./apitest
==325617== 
terminate called after throwing an instance of 'std::runtime_error'
  what():  sdrplay_api_GetDevices() failed
==325617== 
==325617== Process terminating with default action of signal 6 (SIGABRT)
==325617==    at 0x5504A7C: __pthread_kill_implementation (pthread_kill.c:44)
==325617==    by 0x5504A7C: __pthread_kill_internal (pthread_kill.c:78)
==325617==    by 0x5504A7C: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89)
==325617==    by 0x54B0475: raise (raise.c:26)
==325617==    by 0x54967F2: abort (abort.c:79)
==325617==    by 0x4CB1BBD: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==325617==    by 0x4CBD24B: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==325617==    by 0x4CBD2B6: std::terminate() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==325617==    by 0x4CBD517: __cxa_throw (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.30)
==325617==    by 0x10936F: main (apitest.cpp:18)
==325617== 
==325617== HEAP SUMMARY:
==325617==     in use at exit: 77,382 bytes in 19 blocks
==325617==   total heap usage: 25 allocs, 6 frees, 90,734 bytes allocated
==325617== 
==325617== LEAK SUMMARY:
==325617==    definitely lost: 0 bytes in 0 blocks
==325617==    indirectly lost: 0 bytes in 0 blocks
==325617==      possibly lost: 144 bytes in 1 blocks
==325617==    still reachable: 77,238 bytes in 18 blocks
==325617==                       of which reachable via heuristic:
==325617==                         stdstring          : 56 bytes in 1 blocks
==325617==         suppressed: 0 bytes in 0 blocks
==325617== Rerun with --leak-check=full to see details of leaked memory
==325617== 
==325617== For lists of detected and suppressed errors, rerun with: -s
==325617== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
make: *** [Makefile:29: valgrind-apitest] Aborted (core dumped)
dragon@dragon:~/Downloads$ 

alphafox02 avatar Jun 11 '23 10:06 alphafox02

@fventuri

Test 1 on Pi4 w/ aarch64 22.04 and SDRplay Soapy git pull today

ubuntu@ubuntu:~/Downloads$ make valgrind-apitest 
valgrind --track-origins=yes ./apitest
==20475== Memcheck, a memory error detector
==20475== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==20475== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==20475== Command: ./apitest
==20475== 
==20475== 
==20475== HEAP SUMMARY:
==20475==     in use at exit: 0 bytes in 0 blocks
==20475==   total heap usage: 25 allocs, 25 frees, 99,253 bytes allocated
==20475== 
==20475== All heap blocks were freed -- no leaks are possible
==20475== 
==20475== For lists of detected and suppressed errors, rerun with: -s
==20475== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
ubuntu@ubuntu:~/Downloads$ make run-soapytest
./soapytest
Found device #0: driver = sdrplay
label = SDRplay Dev0 RSPdx 2003072543
serial = 2003072543

[INFO] devIdx: 0
[INFO] SerNo: 2003072543
[INFO] hwVer: 4
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
Setting #0:   key=rfgain_sel   name=RF Gain Select   value=4
Setting #1:   key=iqcorr_ctrl   name=IQ Correction   value=true
Setting #2:   key=agc_setpoint   name=AGC Setpoint   value=-30
Setting #3:   key=biasT_ctrl   name=BiasT Enable   value=true
Setting #4:   key=rfnotch_ctrl   name=RfNotch Enable   value=true
Setting #5:   key=dabnotch_ctrl   name=DabNotch Enable   value=true
Done
ubuntu@ubuntu:~/Downloads$ make valgrind-soapytest
valgrind --track-origins=yes ./soapytest
==20716== Memcheck, a memory error detector
==20716== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==20716== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==20716== Command: ./soapytest
==20716== 
Found device #0: driver = sdrplay
label = SDRplay Dev0 RSPdx 2003072543
serial = 2003072543

[INFO] devIdx: 0
[INFO] SerNo: 2003072543
[INFO] hwVer: 4
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
Setting #0:   key=rfgain_sel   name=RF Gain Select   value=4
Setting #1:   key=iqcorr_ctrl   name=IQ Correction   value=true
Setting #2:   key=agc_setpoint   name=AGC Setpoint   value=-30
Setting #3:   key=biasT_ctrl   name=BiasT Enable   value=true
Setting #4:   key=rfnotch_ctrl   name=RfNotch Enable   value=true
Setting #5:   key=dabnotch_ctrl   name=DabNotch Enable   value=true
[ERROR] ReleaseDevice Error: sdrplay_api_ServiceNotResponding
terminate called after throwing an instance of 'std::runtime_error'
  what():  ReleaseDevice() failed
==20716== 
==20716== Process terminating with default action of signal 6 (SIGABRT)
==20716==    at 0x530F200: __pthread_kill_implementation (pthread_kill.c:44)
==20716==    by 0x52CA67B: raise (raise.c:26)
==20716==    by 0x52B712F: abort (abort.c:79)
==20716==    by 0x49B51FB: __gnu_cxx::__verbose_terminate_handler() (in /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30)
==20716==    by 0x49B29DB: ??? (in /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30)
==20716==    by 0x49B1823: ??? (in /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30)
==20716==    by 0x49B205B: __gxx_personality_v0 (in /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30)
==20716==    by 0x526E48B: ??? (in /usr/lib/aarch64-linux-gnu/libgcc_s.so.1)
==20716==    by 0x526E883: _Unwind_RaiseException (in /usr/lib/aarch64-linux-gnu/libgcc_s.so.1)
==20716==    by 0x49B2D17: __cxa_throw (in /usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.30)
==20716==    by 0x993EF2B: SoapySDRPlay::releaseDevice() (in /usr/local/lib/SoapySDR/modules0.8/libsdrPlaySupport.so)
==20716==    by 0x993F167: SoapySDRPlay::~SoapySDRPlay() (in /usr/local/lib/SoapySDR/modules0.8/libsdrPlaySupport.so)
==20716== 
==20716== HEAP SUMMARY:
==20716==     in use at exit: 745,067 bytes in 5,995 blocks
==20716==   total heap usage: 11,284 allocs, 5,289 frees, 1,299,805 bytes allocated
==20716== 
==20716== LEAK SUMMARY:
==20716==    definitely lost: 0 bytes in 0 blocks
==20716==    indirectly lost: 0 bytes in 0 blocks
==20716==      possibly lost: 3,648 bytes in 5 blocks
==20716==    still reachable: 741,419 bytes in 5,990 blocks
==20716==                       of which reachable via heuristic:
==20716==                         stdstring          : 47 bytes in 1 blocks
==20716==         suppressed: 0 bytes in 0 blocks
==20716== Rerun with --leak-check=full to see details of leaked memory
==20716== 
==20716== For lists of detected and suppressed errors, rerun with: -s
==20716== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
make: *** [Makefile:32: valgrind-soapytest] Aborted (core dumped)

Test 2 and so on appeared to have the same results

alphafox02 avatar Jun 11 '23 10:06 alphafox02

What I should have done is first ran the tests with the SoapySDRplay I had on the Pi. I do not recall an issue before. Now that I did a git pull and could see it pulled in a lot of changes from this repo, I seem to be unable to start processing with SigDigger now. SigDigger will open, but upon clicking the start button it just hangs with it saying

SigDigger 
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 2460, resource id: 10577458, major code: 40 (TranslateCoords), minor code: 0
[INFO] devIdx: 0
[INFO] SerNo: 2003072543
[INFO] hwVer: 4
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
[WARNING] Not updating IFGR gain because AGC is enabled
[INFO] Using format CF32.

in the terminal. I'll do further investigation as the Pi and my laptop should both be almost identical in at least they're running 22.04 with the same soapy, api, etc.

alphafox02 avatar Jun 11 '23 11:06 alphafox02

Nevermind that last post, I just didn't leave SigDigger running long enough since I had audio preview on and it needed to build the fftw file. It's running now and does not Seg Fault or have any issues stopping and starting again. I've done it over and over, same result as on my laptop. SDRplay seems fine.

alphafox02 avatar Jun 11 '23 11:06 alphafox02