Segmentation fault when stopping playback With SigDigger develop branch #71
Comments
|
@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 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? ----Steve |
|
@srs4511351 - as you can see in the stack trace you sent, the problem appears to be originated in the method 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 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 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. 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. What can be done? ----Steve |
|
@srs4511351 a minimal test would be roughly the contents of You need to run with valgrind or watch with ASAN to see |
|
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. ----Steve |
|
Save that content to a file Or to use valgrind compile with just If you don't get a crash then some other factor is influencing wether |
|
@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: 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 I ran it again with the additional options 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 Franco |
|
@zuckschwerdt 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 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 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 |
|
@zuckschwerdt /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 I also created a simple @srs4511351 - Steve, please extract these content of the attached zip to an empty directory on your Raspberry Pi, and then run: Here on my Linux x86_64 all three tests (including the one where the program calls 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 |
|
Here is the terminal output from all of the commands that you specify. 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 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 I also added a call to @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: 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. |
|
@alphafox02 - I noticed that the output of the Could you please run If these two 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 Franco |
|
Yes, I just noticed that they were the old tests, sorry. 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 |
|
Test 1 on Pi4 w/ aarch64 22.04 and SDRplay Soapy git pull today 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 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 @srs4511351 - I noticed this line in the output you posted last night (#71 (comment)): That line comes from the 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 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. libgnuradio-soapy3.10.5/stable,now 3.10.5.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. 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 ? 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. |
|
@alphafox02 @srs4511351 - thanks for your tests. @srs4511351 : to answer your question about that 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 Also since SoapySDR C API already has a function called 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, |
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: @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. if (source->settings != NULL)
SoapySDRArgInfoList_clear(source->settings, source->settings_count);
I commented that code out and inserted your debug code. Is the line: 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. My comments are here: |
|
@srs4511351 - first of all thanks for fixing my typo with In order to make 100% sure the problem is in the last call of 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. 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: 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 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 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. |
|
Have you found time yet to try the SigDigger develop branch on a Raspberry Pi with a newer version of SoapySDR? This is the SoapySDR version that crashes SigDigger. Lib Version: v0.8.1-g9c4fa324 |
|
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. 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 |
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)The text was updated successfully, but these errors were encountered: