BatchDrake / sigutils

Small signal processing utility library
https://batchdrake.github.io/sigutils
GNU General Public License v3.0
71 stars 29 forks source link

segfault after changing demodulation type #24

Closed jedi7 closed 2 years ago

jedi7 commented 2 years ago

All build from "develop" branch.

Steps to reproduce: 0) Proposal: run with valgrind.
1) turn on device 2) start switching between FM, LSB, USB .. mostly triggered here .. FM, AM

When use valgrind then probabily is always. Seems there is not enough data to feed which leads to segfault. On valgrind if feeding is really slow, it happens really often. When running in normal mode it is less often (many changes of demodulation)


==794467== Memcheck, a memory error detector
==794467== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==794467== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==794467== Command: ./SigDigger
==794467==
[INFO] Opening Generic RTL2832U OEM :: 00000001...
[INFO] Opening Generic RTL2832U OEM :: 00000001...
[INFO] SoapyRemote::setupRxStream(remoteFormat=CS8, localFormat=CF32, scaleFactor=128, mtu=1500, window=44040192)
[INFO] Client side stream bound to 192.168.111.10:41894
[INFO] Client side status bound to 192.168.111.10:58138
[INFO] Using format CS8.
[INFO] Server side stream bound to [::ffff:192.168.111.4]:57891
[INFO] Server side stream connected to [::ffff:192.168.111.10]:41894
[INFO] Server side status connected to [::ffff:192.168.111.10]:58138
[INFO] Configured sender endpoint: dgram=1452 bytes, 714 elements @ 2 bytes, window=43008 KiB
[INFO] Client side stream connected to 192.168.111.4:57891
[INFO] Configured receiver endpoint: dgram=1452 bytes, 714 elements @ 2 bytes, window=43008 KiB
==794467==
==794467== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==794467==  General Protection Fault
==794467==    at 0x53789E8: ??? (in /usr/lib/libvolk.so.2.5.0)
==794467==    by 0x4991DBA: su_iir_filt_feed (in /usr/lib/libsigutils.so.0.3.0)
==794467==    by 0x4922260: suscan_audio_inspector_feed (in /usr/lib/libsuscan.so.0.3.0)
==794467==    by 0x491D233: suscan_inspector_sampler_loop (in /usr/lib/libsuscan.so.0.3.0)
==794467==    by 0x493FC92: ??? (in /usr/lib/libsuscan.so.0.3.0)
==794467==    by 0x4950155: ??? (in /usr/lib/libsuscan.so.0.3.0)
==794467==    by 0x6BDE258: start_thread (in /usr/lib/libpthread-2.33.so)
==794467==    by 0x706B5E2: clone (in /usr/lib/libc-2.33.so)
==794467==
==794467== HEAP SUMMARY:
==794467==     in use at exit: 67,624,208 bytes in 352,721 blocks
==794467==   total heap usage: 1,464,652 allocs, 1,111,931 frees, 9,233,569,895 bytes allocated
==794467==
==794467== LEAK SUMMARY:
==794467==    definitely lost: 1,683 bytes in 3 blocks
==794467==    indirectly lost: 2,932 bytes in 88 blocks
==794467==      possibly lost: 490,663 bytes in 2,665 blocks
==794467==    still reachable: 67,128,914 bytes in 349,964 blocks
==794467==                       of which reachable via heuristic:
==794467==                         newarray           : 496 bytes in 13 blocks
==794467==                         multipleinheritance: 136,888 bytes in 236 blocks
==794467==         suppressed: 16 bytes in 1 blocks
==794467== Rerun with --leak-check=full to see details of leaked memory
==794467==
==794467== For lists of detected and suppressed errors, rerun with: -s
==794467== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)```
alphafox02 commented 2 years ago

Have noticed this on 20.04 using either a 20.04 based appimage I put together, built with the blsd script, or installed directly from source. Ive also been able to make it happen by opening a subcarrier inspector. It’s easy to reproduce without valgrind for me.

However, I cannot reproduce it with the latest 18.04 based appimage created on here or with the fork I put together. Could you try with this?

I’ll try with valgrind.

https://github.com/BatchDrake/SigDigger/actions/runs/1508709009

jedi7 commented 2 years ago

I'm not using Ubuntu. So I'm compiling it manually by using aur. I updated info about build in ticket.

alphafox02 commented 2 years ago

Could you try the appimage though on your distro just to see if it does the same thing?

BatchDrake commented 2 years ago

This looks like a locking problem in Suscan I may have fixed earlier today. Could you rebuild and try again?

jedi7 commented 2 years ago

Awesome :) you fixed it, thanks

jedi7 commented 2 years ago

ok the issue is solved only partialy. New steps to reproduce:

1) start receiver 2) move to bookmark with modulation LSB (so change will be from FM) 3) see segfault

alphafox02 commented 2 years ago

Can also reproduce as mentioned in source or blsd installed SigDigger in 20.04, however, nothing is reproduced in the 18.04 based appimage used on 20.04. No crashes that is no matter how many times I flip flop and change settings.

I suspect you will also notice a segfault when opening and starting an inspector and then opening and starting a sub carrier inspector.

I think if this gets resolved for you, it’ll likely be resolved in Ubuntu as well.

BatchDrake commented 2 years ago

I believe I've just fixed it. It was some weird memory alignment-related issue in sigutils.

jedi7 commented 2 years ago

fixed, thanks! :)