Closed jedi7 closed 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
I'm not using Ubuntu. So I'm compiling it manually by using aur. I updated info about build in ticket.
Could you try the appimage though on your distro just to see if it does the same thing?
This looks like a locking problem in Suscan I may have fixed earlier today. Could you rebuild and try again?
Awesome :) you fixed it, thanks
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
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.
I believe I've just fixed it. It was some weird memory alignment-related issue in sigutils.
fixed, thanks! :)
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)