Segmentation fault when stopping playback With SigDigger develop branch
Opened this issue · 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: BatchDrake/SigDigger#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) () at /lib/aarch64-linux-gnu/libQt5Core.so.5
#20 0x0000fffff67db258 in QEventLoop::exec(QFlags) () 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 - 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: pothosware/SoapySDR#361 - the comments there by @guruofquality and @zuckschwerdt might be helpful in understanding this problem.
Franco
@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 pothosware/SoapySDR#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 - 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
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 - 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
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 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.
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
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 - 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
@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
@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 BatchDrake/SigDigger#216 (comment)
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?
@srs4511351 sorry, add a first line of #include <stdexcept>
@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
@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
This may be insightful, the problem occurs after a null size allocation: BatchDrake/SigDigger#216 (comment)
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.
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
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 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
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
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 - 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
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 - 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 #71 (comment)
Franco
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
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$
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
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.
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 - thanks for your tests; what branch of SigDigger are you on? If I remember correctly, @srs4511351 is having problems with the develop branch (I think but I am not 100% sure that the master branch of SigDigger works for him)
@srs4511351 - I noticed this line in the output you posted last night (#71 (comment)):
Setting #0: key=gain_ctrl_mode name=Gain Control Mode value=LEGACY
That line comes from the new-gain-controls branch of SoapySDRPlay3, which I think is a few commits behind the master branch.
Would it be possible for you to run SigDigger with the code from the master branch of SoapySDRPlay3, to see if it runs OK with that branch, and the problem is perhaps somewhere in the new-gaincontrols` branch?
Franco
I’m using the develop branch of SigDigger but good catch on the soapy repo. I just did a git pull on what I had Pre built in DragonOS, so I should probably change all that over to your main/master branch. I’ll try again asap on both x86_64 and aarch64
I removed the new-gain-controls install, installed an updated SoapySDRPlay3 master branch and re-ran the tests.
I don't see definitely lost: 24 bytes in 1 blocks this time. Is that something to worry about?
SigDigger is still faulting.
Running soapytest after Digger crashing caused the API not to respond. I ran SoapySDRUtil --probe="driver=sdrplay", which worked and seemed to fix it.
dietpi@DietPi:~/valgrind-tests$ make run-apitest ./apitest dietpi@DietPi:~/valgrind-tests$ make valgrind-apitest valgrind --track-origins=yes ./apitest ==2444== Memcheck, a memory error detector ==2444== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==2444== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==2444== Command: ./apitest ==2444== ==2444== ==2444== HEAP SUMMARY: ==2444== in use at exit: 0 bytes in 0 blocks ==2444== total heap usage: 20 allocs, 20 frees, 80,919 bytes allocated ==2444== ==2444== All heap blocks were freed -- no leaks are possible ==2444== ==2444== For lists of detected and suppressed errors, rerun with: -s ==2444== 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=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 dietpi@DietPi:~/valgrind-tests$ make valgrind-soapytest valgrind --track-origins=yes ./soapytest ==2455== Memcheck, a memory error detector ==2455== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==2455== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==2455== Command: ./soapytest ==2455== 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=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 ==2455== ==2455== HEAP SUMMARY: ==2455== in use at exit: 15,989 bytes in 41 blocks ==2455== total heap usage: 295 allocs, 254 frees, 162,098 bytes allocated ==2455== ==2455== LEAK SUMMARY: ==2455== definitely lost: 0 bytes in 0 blocks ==2455== indirectly lost: 0 bytes in 0 blocks ==2455== possibly lost: 0 bytes in 0 blocks ==2455== still reachable: 15,989 bytes in 41 blocks ==2455== suppressed: 0 bytes in 0 blocks ==2455== Rerun with --leak-check=full to see details of leaked memory ==2455== ==2455== For lists of detected and suppressed errors, rerun with: -s ==2455== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) dietpi@DietPi:~/valgrind-tests$
I noticed that there are some soapy packages that were installed automatically with the gnuradio 3.10.5.1 install.
I also have a SoapySDR installation from 1/14/2023.
It's hard to have the latest versions when the package manager does this. Is there a way around it?
libgnuradio-soapy3.10.5/stable,now 3.10.5.1-3 arm64 [installed,automatic]
libsoapysdr0.8/stable,now 0.8.1-3 arm64 [installed,automatic]
I switched branches, rebuilt and reinstalled SoapySDRplayv3. The test results for api/soapy are the same. I still have no issues using SigDigger, that includes closing it and restarting it.
For reference, this is using this flashed to an SD card on my Pi4.
https://sourceforge.net/projects/dragonos-pi64/
To update SigDigger it's as simple as running sudo ./blsd from within the /usr/src directory and then adjusting SoapySDRplayv3 and making sure to install the SDRplay api that's also sitting in /usr/src. Sorry I can't seem to be of much more help, on my end I can use SDRplay equipment on the Pi w/ SigDigger.
What is ./blsd from within the /usr/src directory ?
Are you sure that you are using the latest SigDigger develop branch for each of its modules?
If you have to wait for fftw to update after having previously run SigSigger, you have an old version of Suscan, as only the develop branch saves this.
Suscan develop branch is where the problem occurs, I know this because is doesn't crash when the following code is removed from Suscan, analyzer/source.c That was a couple of revisions back, so I don't know it it is still there as such.
if (source->settings != NULL) {
for (i = 0; i < source->settings_count; ++i)
SoapySDRArgInfo_clear(source->settings + i);
free(source->settings);
}
Current release and early SigDigger develop branches do not crash.
This system is built using the DietPi bookworm image.
It also has the same problem on a Debian image from https://raspi.debian.net/tested-images/
I need the bookworm distros because SuScan requires a newer version of cmake that what is in bullseye.
@alphafox02 @srs4511351 - thanks for your tests.
@srs4511351 : to answer your question about that definitely lost: 24 bytes in 1 blocks message, I am not really sure at this point if we are in a wild-goose chase trying to figure out these error messages from valgrind.
Looking at those 5 lines of code you in your last comment, it seems to be that SigDigger is using the SoapySDR C API, not C++, since SoapySDRArgInfoList_clear() is declared in Types.h (https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/Types.h#L156).
Also since SoapySDR C API already has a function called SoapySDRArgInfoList_clear(), could you try replacing that for loop and that call to free() with just a call to SoapySDRArgInfoList_clear(), i.e.:
if (source->settings != NULL) {
SoapySDRArgInfoList_clear(source->settings, source->settings_count);
}
Franco
Hi @fventuri
That test you mention was how the clearing of the arguments was implemented when @srs4511351 opened this issue. It failed with the same error. The crash occurs inside the _clear.
Cheers,
What is ./blsd from within the /usr/src directory ? Are you sure that you are using the latest SigDigger develop branch for each of its modules? If you have to wait for fftw to update after having previously run SigSigger, you have an old version of Suscan, as only the develop branch saves this. Suscan develop branch is where the problem occurs, I know this because is doesn't crash when the following code is removed from Suscan, analyzer/source.c That was a couple of revisions back, so I don't know it it is still there as such.
if (source->settings != NULL) {
for (i = 0; i < source->settings_count; ++i)
SoapySDRArgInfo_clear(source->settings + i);
free(source->settings);
}
Current release and early SigDigger develop branches do not crash. This system is built using the DietPi bookworm image. It also has the same problem on a Debian image from https://raspi.debian.net/tested-images/ I need the bookworm distros because SuScan requires a newer version of cmake that what is in bullseye.
Blsd builds all modules from develop branch. The reason fftw had to build was it was a first run, I had messed up. I’m aware of the saving function, I asked for it to be added even in the event of a ctrl c.
@BatchDrake - thanks for the clarification.
In that case I think it would be interesting to temporarily replace those five lines with something like this:
if (source->settings != NULL) {
for (i = 0; i < source->settings_count; ++i) {
SoapySDRArgInfo *setting = source->settings + i;
fprintf(stderr, "setting #%d: %p\n", i, setting);
/* clear strings */
fprintf(stderr, " free(setting->key): %p\n", setting->key);
SoapySDR_free(setting->key);
setting->key = NULL;
fprintf(stderr, " free(setting->value): %p\n", setting->value);
SoapySDR_free(setting->value);
setting->value = NULL;
fprintf(stderr, " free(setting->name): %p\n", setting->name);
SoapySDR_free(setting->name);
setting->name = NULL;
fprintf(stderr, " free(setting->description): %p\n", setting->description);
SoapySDR_free(setting->description);
setting->description = NULL;
fprintf(stderr, " free(setting->units): %p\n", setting->units);
SoapySDR_free(setting->units);
setting->units = NULL;
/* clear options */
fprintf(stderr, " strings_clear(setting->options): %p\n", &setting->options);
SoapySDRStrings_clear(&setting->options, setting->numOptions);
fprintf(stderr, " strings_clear(setting->optionNames): %p\n", &setting->optionNames);
SoapySDRStrings_clear(&setting->optionNames, setting->numOptions);
settings->numOptions = 0;
}
fprintf(stderr, "free(source->settings): %p\n", source->settings);
SoapySDR_free(source->settings);
}
@srs4511351 - would you mind replacing those five lines with the code above in this message, run SigDigger again, let it crash, and then show us the output right before the crash, which should have some of the debug lines I just added?
Franco
The source has changed since that test.
The best I can tell, it is already something like you suggested earlier:
if (source->settings != NULL)
SoapySDRArgInfoList_clear(source->settings, source->settings_count);
I commented that code out and inserted your debug code.
There seems to be a need for variable declarations in suscan/analyzer/source.c?
Is the line:
settings->numOptions = 0;
supposed to be
setting->numOptions = 0;
This is from make:
/home/dietpi/suscan/analyzer/source.c: In function ‘suscan_source_destroy’:
/home/dietpi/suscan/analyzer/source.c:1636:10: error: ‘i’ undeclared (first use in this function)
1636 | for (i = 0; i < source->settings_count; ++i) {
| ^
/home/dietpi/suscan/analyzer/source.c:1636:10: note: each undeclared identifier is reported only once for each function it appears in
/home/dietpi/suscan/analyzer/source.c:1666:7: error: ‘settings’ undeclared (first use in this function); did you mean ‘setting’?
1666 | settings->numOptions = 0;
| ^~~~~~~~
| setting
[ 64%] Building C object CMakeFiles/suscan.dir/analyzer/symbuf.c.o
make[2]: *** [CMakeFiles/suscan.dir/build.make:1042: CMakeFiles/suscan.dir/analyzer/source.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:87: CMakeFiles/suscan.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
So, here is the code that I was able to compile:
unsigned int i;
if (source->settings != NULL) {
for (i = 0; i < source->settings_count; ++i) {
SoapySDRArgInfo *setting = source->settings + i;
fprintf(stderr, "setting #%d: %p\n", i, setting);
/* clear strings */
fprintf(stderr, " free(setting->key): %p\n", setting->key);
SoapySDR_free(setting->key);
setting->key = NULL;
fprintf(stderr, " free(setting->value): %p\n", setting->value);
SoapySDR_free(setting->value);
setting->value = NULL;
fprintf(stderr, " free(setting->name): %p\n", setting->name);
SoapySDR_free(setting->name);
setting->name = NULL;
fprintf(stderr, " free(setting->description): %p\n", setting->description);
SoapySDR_free(setting->description);
setting->description = NULL;
fprintf(stderr, " free(setting->units): %p\n", setting->units);
SoapySDR_free(setting->units);
setting->units = NULL;
/* clear options */
fprintf(stderr, " strings_clear(setting->options): %p\n", &setting->options);
SoapySDRStrings_clear(&setting->options, setting->numOptions);
fprintf(stderr, " strings_clear(setting->optionNames): %p\n", &setting->optionNames);
SoapySDRStrings_clear(&setting->optionNames, setting->numOptions);
setting->numOptions = 0;
}
fprintf(stderr, "free(source->settings): %p\n", source->settings);
SoapySDR_free(source->settings);
}
Here is the output from SigDigger stopping playback and faulting.
setting #0: 0x5582d5c670
free(setting->key): 0x5582620c00
free(setting->value): 0x5582a35120
free(setting->name): 0x5582618b50
free(setting->description): 0x558223a1a0
free(setting->units): 0x55822011a0
strings_clear(setting->options): 0x5582d5c6c0
strings_clear(setting->optionNames): 0x5582d5c6c8
Segmentation fault
For the first test, firefox was running a high CPU load. I closed the offending browser window and re-ran Digger:
setting #0: 0x5592384660
free(setting->key): 0x5591944530
free(setting->value): 0x559165dc30
free(setting->name): 0x55923e8200
free(setting->description): 0x5591659e10
free(setting->units): 0x5591972740
strings_clear(setting->options): 0x55923846b0
strings_clear(setting->optionNames): 0x55923846b8
Segmentation fault
I tried a fresh SigDigger install on a recently installed DietPi bookworm system.
SigDigger does not fault when playback is stopped!
I wonder what's different?
My comments are here:
BatchDrake/SigDigger#216
Look at the bottom.
@srs4511351 - first of all thanks for fixing my typo with setting->numOptions
In order to make 100% sure the problem is in the last call of SoapySDRStrings_clear(), do you mind adding another print statement after that call, in order words could you change the last few lines inside that for loop to something like this:
/* clear options */
fprintf(stderr, " strings_clear(setting->options): %p\n", &setting->options);
SoapySDRStrings_clear(&setting->options, setting->numOptions);
fprintf(stderr, " strings_clear(setting->optionNames): %p\n", &setting->optionNames);
SoapySDRStrings_clear(&setting->optionNames, setting->numOptions);
fprintf(stderr, " after strings_clear(setting->optionNames)\n");
setting->numOptions = 0;
Thanks for the update from the other discussion thread; I wonder what is the difference between the two DietPi bookworm systems.
Franco
I replaced the clear options section with the new code and recompiled.
Here is the output on the faulting system.
setting #0: 0x55872f38b0
free(setting->key): 0x5586f25750
free(setting->value): 0x5586457d20
free(setting->name): 0x5586f10e90
free(setting->description): 0x558682d8c0
free(setting->units): 0x5586751420
strings_clear(setting->options): 0x55872f3900
strings_clear(setting->optionNames): 0x55872f3908
Segmentation fault
This is also posted on BatchDrake/SigDigger#216
On the system where SigDigger was faulting, I uninstalled the compiled SoapySDR (a newer version than the packages that are installed). That broke things because the libSoapySDR.so... name had changed, indicating that it probably had been using the newer libraries.
I had to reinstall these to get it to work again:
SoapySDRPlay
SoapyHackRF
SoapyRTLSDR
gr-osmosdr
Then I reinstalled SigSigger and modules.
It no longer faults when stopping playback.
Are we suspecting a newer SoapySDR?
----Steve
@srs4511351 - Steve I just read your message on the other thread, and I think you might have a good point about SoapySDR.
@alphafox02 - do you mind running the command SoapySDRUtil --info on your Raspberry Pi, and post its output here to see which exact version of SoapySDR you are running, since you don't seem to have any problem with SigDigger crashing?
Franco
On both my desktop and pi it’s the soapy that’s in the apt repo for 22.04. On the pi the specific version says
Lib Version v0.8.1-2build1
API v0.8.0
ABI v0.8
Hope that helps. I’ll uninstall it sometime soon and see if I can cause SigDigger or anything else to crash with soapy from source.
The libSoapySDR.so... name had changed and it broke my system. It will tend to use the name for the old soapy installation, so be sure to remove it.
I had to reinstall these to get it to work again:
SoapySDRPlay
SoapyHackRF
SoapyRTLSDR
gr-osmosdr
I also had to reinstall SigDigger, which seems to have the libSoapySDR.so... name built into it.
Have you found time yet to try the SigDigger develop branch on a Raspberry Pi with a newer version of SoapySDR?
That is the only time that SigDigger crashes when stopping the SDRplay on my system.
This is the SoapySDR version that crashes SigDigger.
From SoapySDRUtil --info
Lib Version: v0.8.1-g9c4fa324
API Version: v0.8.200
ABI Version: v0.8-2
I’d have to go check but on my pi build it’s using 22.04 aarch64 and the repo soapy 8 version. Maybe not as new as you’re showing, but the version it does have does not crash. I could remove it and build from source though asap.
I am fairly certain that the newer version of Soapy is the problem since my system does not crash with the holder one.
That is why we want you to try it.
I hope that this problem could be resolved, as the newer version will be more common in the future.
Upgrading Soapy could break other things the depend on it, so it may be worth spending a few bucks on a new SD card and build a new system. I have several.
----Steve