Segmentation fault when stopping playback #216
Comments
|
Hi Steve, Could you run SigDigger from gdb and from there, copy here the backtrace of the error? You can do this by running SigDigger from terminal like this: Then, from the gdb prompt, type run: Wait for SigDigger to start, make it crash, and then print a backtrace with this: Regarding your question on Cmake, I am afraid we need 3.20 or higher. We introduced extensive build system restructuring some time ago, and 3.18 is no longer enough :( |
|
Thread 1 "SigDigger" received signal SIGSEGV, Segmentation fault. |
|
Hi, I'll try to fix this during the day. In the meantime, inside of Suscan, go to analyzer/source.c and in the surroundings of line 1635, remove the following lines: if (source->settings != NULL) {
for (i = 0; i < source->settings_count; ++i)
SoapySDRArgInfo_clear(source->settings + i);
free(source->settings);
}Rebuild, and tell me if it keeps crashing Cheers, |
|
SigDigger no longer crashes when I stop reception. ----Steve |
|
Hi again, I've been trying to reproduce this crash, but no luck so far. Few things I see in your setup:
Cheers, |
|
I have to boot to another system to see if the crash occurs on my other SDRs. My SoapySDR was installed from source on 1/22/2023. |
|
I have nearly the same setup, except I’m running 22.04 aarch64, but can’t test till I return next week. If it’s okay to ask, since it’s a different issue, could you try and stop the sdrplay service? Then start SigDigger again on the same Pu and same profile you used the RSP1A with, try to start SigDigger from command line and observe. I find that if there’s a profile for sdrplay and the service has gotten messed up (happens under certain situations) SigDigger will take forever to load as it just keeps trying to reach the radio. I’m only asking here since you happen to have the same hardware. |
|
I booted a Raspberry Pi OS bullseye system that has the same crash. ----Steve |
|
@alphafox02 Simply stopping the SDRplay service causes many errors like: The device is not in the list of devices. ----Steve |
|
Sorry I was asking you and I meant Pi. I realize it causes errors, I was trying to provide a way to simulate the service failed. What I was saying is that once there’s a profile in SigDigger for the sdrplay device it ends up causing issues the next time SigDigger tries to start if something has happened to the sdrplay service, fixable by resetting the service of course. I can make a separate ticket with details and I’ll test what you’re seeing as soon as I can. |
|
It sounds like my test is what you wanted. SigDigger does look for the SDRplay and errors if it wasn't found. Stopping and starting the API will sometimes gets the API working again. I have seen issues when the SDRplay is opened by certain applications the first time after a boot/reboot, that the API crashes. Edit: I ran SigDigger as the first application after reboot to access the SDRplay SDR. It did not crash. ----Steve |
|
Okay, in this case I am going to mark this as 3rd-party (this is actually one of the multiple SDRPlay library/module bugs) and close this issue. You should report this here: https://github.com/pothosware/SoapySDRPlay3 |
|
Since this developed at some point during work on the develop branch, I suggest that you may be able to do something about it. This does not happen with the release version and early develop branch installations like the version detailed below. I don't know what to sat to the SoapySDR developer about this. |
|
I received a reply from @fventuri about this problem. In the issue that I opened, pothosware/SoapySDRPlay3#71 he said: If you could look this over, I hope it will help you. ----Steve |
|
Hi, I've just changed the way we free the argument info list. Now it is done exactly as how @guruofquality describes. Can you build again from develop and see if it keeps crashing? Cheers, |
|
Do I only need to rebuild suscan? I can do it later in the morning. ----Steve |
|
Yes, I just changed the implementation of something, so it should be fine. |
|
I tried to install suscan, but make failed with errors: [ 22%] Building C object CMakeFiles/suscan.dir/analyzer/inspector/interface.c.o
/home/dietpi/suscan/analyzer/inspector/inspector.c:66:5: error: unknown type name ‘su_specttuner_channel_data_func_t’; did you mean ‘su_specttuner_channel_t’?
66 | su_specttuner_channel_data_func_t on_data,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| su_specttuner_channel_t
/home/dietpi/suscan/analyzer/inspector/inspector.c:67:5: error: unknown type name ‘su_specttuner_channel_new_freq_func_t’
67 | su_specttuner_channel_new_freq_func_t on_new_freq,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[ 23%] Building C object CMakeFiles/suscan.dir/analyzer/inspector/overridable.c.o
In file included from /usr/local/include/sigutils/sigutils/block.h:28,
from /usr/local/include/sigutils/sigutils/sigutils.h:23,
from /home/dietpi/suscan/analyzer/inspector/inspector.c:28:
/home/dietpi/suscan/analyzer/inspector/inspector.c: In function ‘suscan_sc_inspector_factory_open’:
/home/dietpi/suscan/analyzer/inspector/inspector.c:210:13: warning: implicit declaration of function ‘suscan_inspector_open_sc_channel_ex’; did you mean ‘suscan_inspector_open_sc_close_channel’? [-Wimplicit-function-declaration]
210 | schan = suscan_inspector_open_sc_channel_ex(
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/sigutils/sigutils/defs.h:110:9: note: in definition of macro ‘SU_TRYCATCH’
110 | if (!(expr)) { \
| ^~~~
/home/dietpi/suscan/analyzer/inspector/inspector.c:210:11: warning: assignment to ‘su_specttuner_channel_t *’ {aka ‘struct sigutils_specttuner_channel *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
210 | schan = suscan_inspector_open_sc_channel_ex(
| ^
/usr/local/include/sigutils/sigutils/defs.h:110:9: note: in definition of macro ‘SU_TRYCATCH’
110 | if (!(expr)) { \
| ^~~~
make[2]: *** [CMakeFiles/suscan.dir/build.make:398: CMakeFiles/suscan.dir/analyzer/inspector/inspector.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
Guessing that I need to reinstall sigutils, I got more errors: cmake ..
CMake Error at CMakeLists.txt:28 (include):
include could not find requested file:
GitVersionDetect
CMake Error at CMakeLists.txt:35 (project):
VERSION ".." format invalid.
-- Configuring incomplete, errors occurred!
What do I need to install to get GitVersionDetect? |
|
You have to clone sigutils with recurse submodules: |
|
From https://github.com/antoniovazquezblanco After I did that, I see your recurse submodules, but although SigDigger runs and receives signals, I still get the Segmentation fault. Should I start the installations over with recurse submodules? I can get a gdb trace, but I have to install a lot if things to get gdb installed on the system I am using. |
|
Yes, I thought you had a more recent version, my bad. The ABI changed a lot since you last built SigDigger, so you need to rebuild everything from Sigutils to SigDigger. |
|
I reinstalled everything for SigDigger and modules. It runs normally, but faults when I stop reception. Thread 1 "SigDigger" received signal SIGSEGV, Segmentation fault.
0x0000007ff60ff610 in free () from /lib/aarch64-linux-gnu/libc.so.6
(gdb) bt
#0 0x0000007ff60ff610 in free () from /lib/aarch64-linux-gnu/libc.so.6
#1 0x0000007ff7cabd50 in SoapySDRStrings_clear ()
from /usr/local/lib/libSoapySDR.so.0.8-2
#2 0x0000007ff7cac294 in SoapySDRArgInfo_clear ()
from /usr/local/lib/libSoapySDR.so.0.8-2
#3 0x0000007ff7cac2e8 in SoapySDRArgInfoList_clear ()
from /usr/local/lib/libSoapySDR.so.0.8-2
#4 0x0000007ff7e87c78 in suscan_source_destroy (source=0x5556ef76b0)
at /home/dietpi/suscan/analyzer/source.c:1632
#5 0x0000007ff7e6a6c4 in suscan_local_analyzer_dtor (ptr=0x5556ab1e30)
at /home/dietpi/suscan/analyzer/impl/local.c:904
#6 0x0000007ff7e61ea8 in suscan_analyzer_destroy (self=0x5556ef75e0)
at /home/dietpi/suscan/analyzer/analyzer.c:671
#7 0x00000055557022a8 in Suscan::Analyzer::~Analyzer() ()
#8 0x00000055557022d8 in Suscan::Analyzer::~Analyzer() ()
#9 0x0000005555608608 in SigDigger::Application::orderedHalt() ()
#10 0x000000555560b084 in SigDigger::Application::onAnalyzerHalted() ()
#11 0x0000007ff681a608 in ?? () from /lib/aarch64-linux-gnu/libQt5Core.so.5
#12 0x0000007ff680e6cc in QObject::event(QEvent*) ()
from /lib/aarch64-linux-gnu/libQt5Core.so.5
#13 0x0000007ff74ac0a0 in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() from /lib/aarch64-linux-gnu/libQt5Widgets.so.5
#14 0x0000007ff67dcd40 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
--Type for more, q to quit, c to continue without paging--c
() from /lib/aarch64-linux-gnu/libQt5Core.so.5
#15 0x0000007ff67e00a8 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/aarch64-linux-gnu/libQt5Core.so.5
#16 0x0000007ff683f4e8 in ?? () from /lib/aarch64-linux-gnu/libQt5Core.so.5
#17 0x0000007ff4f5774c in g_main_context_dispatch ()
from /lib/aarch64-linux-gnu/libglib-2.0.so.0
#18 0x0000007ff4f579e0 in ?? () from /lib/aarch64-linux-gnu/libglib-2.0.so.0
#19 0x0000007ff4f57a84 in g_main_context_iteration ()
from /lib/aarch64-linux-gnu/libglib-2.0.so.0
#20 0x0000007ff683eaa8 in QEventDispatcherGlib::processEvents(QFlags) () from /lib/aarch64-linux-gnu/libQt5Core.so.5
#21 0x0000007ff67db258 in QEventLoop::exec(QFlags) () from /lib/aarch64-linux-gnu/libQt5Core.so.5
#22 0x0000007ff67e42dc in QCoreApplication::exec() ()
from /lib/aarch64-linux-gnu/libQt5Core.so.5
#23 0x00000055556034f0 in main ()
(gdb)
----Steve |
|
Well, I did it how @guruofquality instructed. This only fails with SDRPlay. It fails because now I use this API to clear the argument info I previously retrieved. |
|
Look, let us try this (this is going to make SigDigger run absolutely slow and will take a few minutes to start up, but will generate an interesting log). Install valgrind from the repos, and run: Repeat the process that makes SigDigger crash (even if it does not crash after all), and send the |
|
Perhaps the SoapySDR people can help. My other applications work. ----Steve |
|
I will install the package: |
|
If this is a double-free error then ASAN might be able to track that and give a detailed output. A debug build should only need then e.g. |
|
SigDigger did not run. I got a Segmentation fault. Correction: SigDigger did start, it displayed the splash screen before faulting. |
|
The interesting part is right at the start
|
|
This time, the application crashed on startup. |
|
It is probably related. The crash you se there probably corrupts the heap if you are not using Valgrind. My guess is that the SDRPlay library is corrupting the memory leaving the heap in an invalid state, and things crash at the free. |
|
Hi, I am reviewing the log file again. As I can see, the log has two interesting lines here: The first one states that "select device" fails, i.e. the SDRPlay device is not being found. The second one states that the error is inline |
|
Quick question and I can’t recall if it’s already been answered, but can you guys w/ sdrplay equipment download and live boot the latest DragonOS FocalX that already had SigDigger and sdrplay api installed and see if it’s the same issue? To rebuild to the latest SigDigger. Suscli etc on it just change to /usr/src and run sudo ./blsd Besides having an issue if sdrplay has crashed or isn’t running, I’ve not experienced an issue as described above. I’ll try it again today though. |
IIRC that is the call site not callee, so |
|
With SelectDevice Error: sdrplay_api_ServiceNotResponding, the API must have been crashed. I have attached the new log. |
|
Now I see the error true error: The error is happening in |
|
SigDigger had been crashing on several OS installations that I have. Today, I did a fresh SigDigger install on a recently installed DietPi bookworm system. SoapySDR is installed from the system packages and not from source like the other systems. The soapy packages for the specific SDRs are installed from source as are the other systems. I would like to know what is wrong with the other systems. Could the compiler optimization flags effect it? ----Steve |
|
Hi, Nah, I don't think so. My bet is that there was a bug in SoapySDR that was fixed by the Debian people but not upstream. What SoapySDR version did you have earlier? |
|
On the system that faults, I have SoapySDR installed from source on 1/14/2023. From SoapySDRUtil --info Lib Version: v0.8.1-g9c4fa324 There are also these packages installed that came along with the gnuradio 3.10 installation. It looks like Soapy is using the newer version? The OS is DietPi v8.18.2, the same version as the new one, only it has been upgraded. |
|
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? |
|
Probably. Or something as simple as ABI incompatibilities. |
|
In any case, if this is fixed, is there anything else I can help you with? |
|
My installation is fixed, but it is not resolved. As for other things, I have some operational issues. ----Steve |
|
The problem is that I cannot reproduce none of these issues. This does not happen with any of my radios, so my hands are tied here. Regarding the other things, could you open separate issues for them? That way would be much easier to track their resolution status. |
Computer:
Raspberry Pi 4
Debian GNU/Linux 12 (bookworm)
SDRplay RSP1A
develop branch
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 takes a few minutes to start reception.
A few minutes after that, audio preview starts.
I assume that this is due to not having fftwisdom saved.
SigDigger seems to work normally.
When I press the Run button to stop reception, SigDigger closes and Segmentation fault appears on the terminal.
This does not happen with the release version and early develop branch installations like the version detailed below.
SigDigger 0.3.0 custom build Nov 24 2022 (10.2.1)
Using suscan version 0.3.0 (custom build on Nov 24 2022 at 23:12:12 (10.2.1 20210110))
Using sigutils version 0.3.0 (custom build on Nov 24 2022 at 23:09:37 (10.2.1 20210110))
I prefer the develop branch because the startup delay is quite long on previous versions.
With the develop branch of sigutils, CMake 3.20.0 or higher is required. The version on the Raspberry Pi distribution is cmake version 3.18.4. Can you make sigutils build with cmake version 3.18.4?
-----Steve
The text was updated successfully, but these errors were encountered: