SIGSEGV with memcpy() in rx_meter_c::work() (src/dsp/rx_meter.cpp:73) on FreeBSD about gqrx HOT 16 CLOSED

Thanks a lot for your help, Clayton! I'll give it a try and tell you how it goes :)

from gqrx.

Hi there,

I can't reproduce this on Linux or MacOS. The buffer size calculations look correct, and I'm starting to suspect there could be an issue with GNU Radio's double-mapped buffers on FreeBSD.

from gqrx.

I installed GNU Radio on FreeBSD and immediately ran into a similar segfault when attempting to run a simple flow graph (Noise Source --> Throttle --> Null Sink). So it would seem that the issue lies in GNU Radio or FreeBSD's GNU Radio package, rather then Gqrx.

from gqrx.

Hello @argilo

Thanks for your reply and investigation. Well, I'll try to investigate on the GNURadio side then !

Best regards,

Ganael.

from gqrx.

Hello,

I could reproduce the immediate crash you are observing, it is related to ASLR. Gnuradio seems to have problems when it is enabled. If you disable it globally with (before running Gr flow's python code) :

# sysctl kern.elf64.aslr.enable=0

your simple flow graph (Noise Source --> Throttle --> Null Sink) will not crash anymore.

Actually, I had to disable ASLR for Gqrx to make it work again when ASLR has been turned on by default on FreeBSD, see:

https://cgit.freebsd.org/ports/commit/?id=f05f6dcedb5dad5b7b515ebede9bf6a58de1d46c

so Gqrx' crash I am writing about here is not related as what you are observing happens with ASLR disabled.

The backtrace above clearly shows an access to an invalid write pointer during memcpy() (see: /usr/ports/comms/gqrx/work/gqrx-2.16/src/dsp/rx_meter.cpp:73) that triggers SIGSEGV.

What I don't know is if it is due to a bug in Gqrx code or in Gnuradio buffers handling on FreeBSD :/

If you want to reproduce the issue on FreeBSD and need help, do not hesitate to contact me, I'll help you setting things up.

Best regards,

Ganael.

from gqrx.

An interesting thing: if I start Gqrx with WFM preselected and just turn DSP on, it does not crash. Problems arise when changing DSP mode (e.g. AM -> WFM x). Could there be a problem with de-allocation/re-allocation of Gr buffers when switching mode ?

from gqrx.

This may be related to #1265. The fix also requires GNU Radio v3.10.7.0, which fixes a bug in buffer size limts.

from gqrx.

Hello Jeff,

Thanks for your feedback.

This does not appear to be the same symptom as in #1233 (fixed by PR #1265): the DSP does not hang, but Gqrx crashes with SIGSEGV.

Unfortunately, the same bug still occurs with Gnuradio 3.10.7.0 and latest master (d7219a6) from Gqrx.

from gqrx.

@martymac I did some more digging, and it appears the issue lies in GNU Radio. I used truss to monitor allocation of GNU Radio's double-mapped buffers, and it can be seen that the buffer that causes a segfault in Gqrx is not contiguous:

getpid()                                         = 1230 (0x4ce)
shm_open2("/gnuradio-1230-20",O_RDWR|O_CREAT|O_EXCL|O_CLOEXEC,0600,0,"(null)") = 21 (0x15)
ftruncate(21,0x408000)                           = 0 (0x0)
mmap(0x0,4227072,PROT_READ|PROT_WRITE,MAP_SHARED,21,0x0) = 34758197248 (0x817c00000)
munmap(0x817e04000,2113536)                      = 0 (0x0)
mmap(0x817e04000,2113536,PROT_READ|PROT_WRITE,MAP_SHARED,21,0x0) = 34762391552 (0x818000000)
close(21)                                        = 0 (0x0)
shm_unlink("/gnuradio-1230-20")                  = 0 (0x0)

GNU Radio requested that the second half of the double-mapped buffer be allocated at 0x817e04000 (immediately after the first half), but the kernel did not accept this hint and instead allocated it at 0x818000000. Gqrx segfaults as soon as it attempts to write beyond the end of the first half of the double-mapped buffer.

GNU Radio's vmcircbuf_mmap_shm_open::vmcircbuf_mmap_shm_open constructor does not check for discontiguity:

https://github.com/gnuradio/gnuradio/blob/f5d35bcfc137c6314545a16300a8e75e684359f0/gnuradio-runtime/lib/vmcircbuf_mmap_shm_open.cc#L111-L124

Interestingly, one of the other double-mapped buffer implementations (vmcircbuf_mmap_tmpfile::vmcircbuf_mmap_tmpfile) does have a contiguity check, although it simply raises a std::runtime_error if the allocation was discontiguous:

https://github.com/gnuradio/gnuradio/blob/f5d35bcfc137c6314545a16300a8e75e684359f0/gnuradio-runtime/lib/vmcircbuf_mmap_tmpfile.cc#L98-L121

from gqrx.

mmap has a MAP_FIXED flag which indicates that the exact addr value must be used. Perhaps GNU Radio should be using that.

from gqrx.

The crash in the simple flow graph when ASLR is enabled appears to have the same root cause; truss shows that a discontiguous double-mapped buffer is allocated in that case as well.

from gqrx.

The order of precedence is

• vmcircbuf_createfilemapping
• vmcircbuf_sysv_shm
• vmcircbuf_mmap_shm
• vmcircbuf_mmap_tmpfile

Linux seems to work with sysv and createfilemapping is for windows, so the mmap versions probably don't get tested much. I take it FreeBSD doesn't have sysv IPC?

from gqrx.

I opened a pull request, which I hope will fix this: gnuradio/gnuradio#6854

@martymac Would you be able to take this for a spin on FreeBSD? I expect that things should work correctly even when ALSR is enabled.

from gqrx.

Closing, since the root cause was a bug in GNU Radio, which was fixed in gnuradio/gnuradio#6854.

from gqrx.

Glad I could help.

If you run into any trouble after applying the GNU Radio patch, let me know.

from gqrx.

Everything seems to be working fine with your patch :) Thanks again for your precious help!

from gqrx.