Re: Frame drop when Using GMSK en UDP

[Alex Roberts]

Quenten, Have you looked at any of the gr-dtv examples? Instead of pulling
into GRC with UDP, you could pull the video stream and convert to mpeg-TS
with either gstreamer or ffmpeg and stream it to a fifo file. The gr-dtv
examples are great for reading in TS files and broadcasting. I've done this
with gstreamer and gr-isdbt.

On Fri, Apr 24, 2020 at 8:57 AM Marcus Müller  wrote:

> Hi Quenten,
>
> do you mean a bandwidth of 1.25 MHz, up to at most 20 MHz? Or do you
> mean carrier frequency? Or do you mean occupied spectrum spans from 1.25
> MHz to 20 MHz (i.e. 18.75 MHz bandwidth)? In the latter two cases: I'd
> be interested in how you build a very wideband antenna for these
> extraordinarily low frequencies; that is very hard!
>
> I don't see how that precludes OFDM; quite on the contrary, all three
> options actually sounds like a very classical use cases of OFDM.
>
> Best regards,
>
> Marcus
>
> On 4/24/20 1:59 PM, Quenten . wrote:
> > Thanks for the tip.
> > I did 1 and 2  (but didn't find  a gr-digital map in the examples on
> > GRC software), and what do you mean with: "it's misconfigured".
> > Also you say that OFDM would be interesting(It normally would) but
> > because of some circumstances I can't use OFDM. It is because its
> > frequency spectrum is to low (1.25MHz to 20MHz). But the frequency
> > spectrum that I am later gonna use is from 300 MHz to 3.8GHz (because
> > I am gonna use a bladeRFx115 eventually as the HW component).
> >
> > Best regards,
> >
> > Quenten
> >
> > Op vr 24 apr. 2020 om 12:32 schreef Marcus Müller
> > mailto:mmuel...@gnuradio.org>>:
> >
> > Hi Quenten,
> >
> > you're using multiple deprecated blocks; especially the packet
> > encooder/decoder are simply buggy and drop data. (Also, it's
> > misconfigured, but properly configuring it won't help. Don't use it.)
> >
> > Also, while your computer might be too slow, the Throttle guarantees
> > that the UDP source has to drop UDP packets if your data rate is
> > higher
> > than 500 kB/s...
> >
> > So,
> >
> > 1. Replace deprecated WX GUI with Qt GUI
> >
> > 2. Remove all throttles
> >
> > 3. replace packet encoder/decoder with appropriate packet
> > transmission
> > example from gr-digital
> >
> >
> > You'll notice that a video stream is a lot of data, and that 500 kHz
> > bandwidth simply won't do with GMSK to transport that amount of data.
> > Which means you'll need more bandwidth. Which means you'll see a
> > frequency-selective channel. Which means you need some
> > equalization, or
> > a multicarrier scheme! The OFDM-examples in gr-digital will be of
> > most
> > interest to you.
> >
> > Best regards,
> >
> > Marcus
> >
> > On 4/24/20 10:05 AM, Quenten . wrote:
> > > Hello,
> > > I am trying to stream (de)mod a live video with to use of GNU
> > radio.
> > > from my windows 10 PC. These are the steps I follow:
> > > 1)Steam using OBS to an RTMP server
> > > 2)Use ffmpeg to get this stream form OBS and send it to UDP
> > (port:
> > > ; IP:127.0.0.1).
> > > 3) Do GMSK mod en demod
> > > 4) Save it to a file sink
> > >
> > > Here is the program:
> > > image.png
> > > I also get a warning from GNU: *WARN: Too much data; dropping
> > packet.
> > > *But I think this is because my PC is to slow.
> > >
> > > If someone can help it would be appreciated.
> > >
> > > Best regards,
> > >
> > > Q
> >
>
>

Again on FCDPROPLUS

[Vincenzo Mone]

Hello,

Please I have a doubt.

Reading on the FCDPROPLUS site I read:

 

3.  Important

Don't forget the udev rules: For instance:

Udev rules for the Funcube Dongle Pro (0xfb56) and Pro+ (0xfb31)

HIDAPI/libusb:

SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8" ATTRS{idProduct}=="fb56"
MODE:="0666" SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8"
ATTRS{idProduct}=="fb31" MODE:="0666"

HIDAPI/hidraw:

KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
ATTRS{idProduct}=="fb56", MODE="0666" KERNEL=="hidraw*", ATTRS{busnum}=="1",
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="fb31", MODE="0666

 

Please what does it means?

Maybe I am missing something.

Any help?

Thanks

 

73 de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520




  *

  **   GSM  +39 328 7110193  **

  * SMS  +39 328 7110193*

  *

 

Re: Gnuradio 3.7

[Marcus Müller]

Hi Vincenzo,

although rebuilding the Ubuntu GNU Radio package for 18.04 should in
theory be pretty straightforward:

We do still maintain GNU Radio 3.7, in the sense that we're fixing bugs,
and making sure that nothing breaks it on existing installations.
What we don't actively do is try to forward-port it to newer distro
versions, so you're kind of on your own here. Also, I'm almost certain
you *should* be using 3.8, after all we talked about.

Best regards,
Marcus

On 26.04.20 15:25, Vincenzo Mone wrote:
> Please I own the UBUNTU 20.04 LTS.
> 
> I do not want to use the latest 3.8 Gnuradio-Companion but
> 
> I would like to install the 3.7 version.
> 
> Please anybody can point me step by step how to do?
> 
> Thanks
> 
>  
> 
> 73 de Enzo IK8OZV
> EasyLog 5 BetaTester
> EasyLog PDA BetaTester
> WinBollet BetaTester
> D.C.I. CheckPoint Regione Campania
> Skype: ik8ozv8520
> 
> 
> 
> 
>   *
> 
>   **   GSM  +39 328 7110193  **
> 
>   * SMS  +39 328 7110193    *
> 
>   *
> 
>  
> 

Re: Release 3.8.1 on ubuntu 18.04 qa_qtgui (Failed) with Segmentation fault

[Marcus Müller]

Hi Joe,

I'm not ruling out this is a GNU Radio bug, but I find it rather
unlikely; your complete call trace doesn't ever wander into any GNU
Radio libraries, but:

> ==22123==by 0x13B1D604: QPrinterInfoPrivate (qprinterinfo_p.h:71)

Sounds like you've either found a bug in Qt (unlikely), or you're mixing
multiple versions of QT somehow on your machine. Is that possible?

Best regards,
Marcus
On 26.04.20 14:13, Joe D wrote:
> 
> Thanks Vasil for correcting my approach
> 
> below the relevant excerpt from the new valgrind log
> 
> Attached the full one
> 
> Regarding gdb , is there any additional steps to load the symbols or the
> instruction on https://wiki.gnuradio.org/index.php/TutorialsDebugging
> will suffice
> 
> ==22123== Process terminating with default action of signal 11
> (SIGSEGV): dumping core
> ==22123==  Bad permissions for mapped region at address 0x104C66C0
> ==22123==    at 0x13B1D604: ref (qlist.h:121)
> ==22123==    by 0x13B1D604: QList (qlist.h:121)
> ==22123==    by 0x13B1D604: QPrinterInfoPrivate (qprinterinfo_p.h:71)
> ==22123==    by 0x13B1D604: __static_initialization_and_destruction_0
> (qprinterinfo.cpp:35)
> ==22123==    by 0x13B1D604: _GLOBAL__sub_I_qprinterinfo.cpp
> (qprinterinfo.cpp:163)
> ==22123==    by 0x4010732: call_init (dl-init.c:72)
> ==22123==    by 0x4010732: _dl_init (dl-init.c:119)
> ==22123==    by 0x40151FE: dl_open_worker (dl-open.c:522)
> ==22123==    by 0x4FA32DE: _dl_catch_exception (dl-error-skeleton.c:196)
> ==22123==    by 0x40147C9: _dl_open (dl-open.c:605)
> ==22123==    by 0x544CF95: dlopen_doit (dlopen.c:66)
> ==22123==    by 0x4FA32DE: _dl_catch_exception (dl-error-skeleton.c:196)
> ==22123==    by 0x4FA336E: _dl_catch_error (dl-error-skeleton.c:215)
> ==22123==    by 0x544D734: _dlerror_run (dlerror.c:162)
> ==22123==    by 0x544D050: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
> ==22123==    by 0x5F7DBC: _PyImport_FindSharedFuncptr (in
> /usr/bin/python3.6)
> ==22123==    by 0x5FB027: _PyImport_LoadDynamicModuleWithSpec (in
> /usr/bin/python3.6)
> ==22123==
> ==22123== HEAP SUMMARY:
> ==22123==     in use at exit: 5,615,552 bytes in 7,555 blocks
> ==22123==   total heap usage: 25,234 allocs, 17,679 frees, 48,677,061
> bytes allocated
> ==22123==
> ==22123== LEAK SUMMARY:
> ==22123==    definitely lost: 157,672 bytes in 86 blocks
> ==22123==    indirectly lost: 0 bytes in 0 blocks
> ==22123==      possibly lost: 230,559 bytes in 220 blocks
> ==22123==    still reachable: 5,227,321 bytes in 7,249 blocks
> ==22123==                       of which reachable via heuristic:
> ==22123==                         newarray           : 1,536 bytes in 16
> blocks
> ==22123==         suppressed: 0 bytes in 0 blocks
> ==22123== Rerun with --leak-check=full to see details of leaked memory
> ==22123==
> ==22123== For counts of detected and suppressed errors, rerun with: -v
> ==22123== Use --track-origins=yes to see where uninitialised values come
> from
> ==22123== ERROR SUMMARY: 11565 errors from 209 contexts (suppressed: 0
> from 0)
> Segmentation fault
> 
> On Sun, Apr 26, 2020 at 9:27 PM Vasil Velichkov  > wrote:
> 
> Hi Joe,
> 
> On 26/04/2020 14.01, Joe D wrote:
> > Attached a valgrind log
> 
> >>
> root@ubuntu-srv-10:/Applications/gnuradio/build/gr-qtgui/python/qtgui#
> valgrind -v ctest -V -R qa_qtgui
> 
> You can't run this test under valgrind like this. You need to open
> ./build/gr-qtgui/python/qtgui/qa_qtgui_test.sh and on the last line
> add valgrind in front of python3. Something like:
> 
>     valgrind /usr/bin/python3 -B
> /Applications/gnuradio/gr-qtgui/python/qtgui/qa_qtgui.py
> 
> Similarly you can run it under gdb in order to get a full backtrace
> of this segfault.
> 
> Regards,
> Vasil
> 

Gnuradio 3.7

[Vincenzo Mone]

Please I own the UBUNTU 20.04 LTS.

I do not want to use the latest 3.8 Gnuradio-Companion but

I would like to install the 3.7 version.

Please anybody can point me step by step how to do?

Thanks

 

73 de Enzo IK8OZV
EasyLog 5 BetaTester
EasyLog PDA BetaTester
WinBollet BetaTester
D.C.I. CheckPoint Regione Campania
Skype: ik8ozv8520




  *

  **   GSM  +39 328 7110193  **

  * SMS  +39 328 7110193*

  *

 

Re: Release 3.8.1 on ubuntu 18.04 qa_qtgui (Failed) with Segmentation fault

[Vasil Velichkov]

Hi Joe,

On 26/04/2020 15.13, Joe D wrote:

> Regarding gdb , is there any additional steps to load the symbols or the
> instruction on https://wiki.gnuradio.org/index.php/TutorialsDebugging will
> suffice

I'm not familiar with this tutorial, for gnuradio's symbols it should be enough 
to rebuild in "RelWithDebInfo" or "Debug" mode.

rm CMakeCache.txt
cmake -D CMAKE_BUILD_TYPE=RelWithDebInfo ..
make clean 
make

For debug symobols of external libraries you need to install their dbg or 
dbgsym packages:

https://wiki.ubuntu.com/DebuggingProgramCrash
https://wiki.debian.org/HowToGetABacktrace

> 
> ==22123== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
> ==22123==  Bad permissions for mapped region at address 0x104C66C0
> ==22123==at 0x13B1D604: ref (qlist.h:121)
> ==22123==by 0x13B1D604: QList (qlist.h:121)
> ==22123==by 0x13B1D604: QPrinterInfoPrivate (qprinterinfo_p.h:71)
> ==22123==by 0x13B1D604: __static_initialization_and_destruction_0
> (qprinterinfo.cpp:35)
> ==22123==by 0x13B1D604: _GLOBAL__sub_I_qprinterinfo.cpp
> (qprinterinfo.cpp:163)
> ==22123==by 0x4010732: call_init (dl-init.c:72)
> ==22123==by 0x4010732: _dl_init (dl-init.c:119)
> ==22123==by 0x40151FE: dl_open_worker (dl-open.c:522)
> ==22123==by 0x4FA32DE: _dl_catch_exception (dl-error-skeleton.c:196)
> ==22123==by 0x40147C9: _dl_open (dl-open.c:605)
> ==22123==by 0x544CF95: dlopen_doit (dlopen.c:66)
> ==22123==by 0x4FA32DE: _dl_catch_exception (dl-error-skeleton.c:196)
> ==22123==by 0x4FA336E: _dl_catch_error (dl-error-skeleton.c:215)
> ==22123==by 0x544D734: _dlerror_run (dlerror.c:162)
> ==22123==by 0x544D050: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
> ==22123==by 0x5F7DBC: _PyImport_FindSharedFuncptr (in
> /usr/bin/python3.6)
> ==22123==by 0x5FB027: _PyImport_LoadDynamicModuleWithSpec (in
> /usr/bin/python3.6)

This looks like https://github.com/gnuradio/gnuradio/issues/3215 and 
https://github.com/gnuradio/gnuradio/issues/2895

If you have libqt4-dev installed on your system and you don't need it for 
something else you may try to uninstall it.

Regards,
Vasil

Re: Release 3.8.1 on ubuntu 18.04 qa_qtgui (Failed) with Segmentation fault

[Joe D]

Thanks Vasil for correcting my approach

below the relevant excerpt from the new valgrind log

Attached the full one

Regarding gdb , is there any additional steps to load the symbols or the
instruction on https://wiki.gnuradio.org/index.php/TutorialsDebugging will
suffice

==22123== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==22123==  Bad permissions for mapped region at address 0x104C66C0
==22123==at 0x13B1D604: ref (qlist.h:121)
==22123==by 0x13B1D604: QList (qlist.h:121)
==22123==by 0x13B1D604: QPrinterInfoPrivate (qprinterinfo_p.h:71)
==22123==by 0x13B1D604: __static_initialization_and_destruction_0
(qprinterinfo.cpp:35)
==22123==by 0x13B1D604: _GLOBAL__sub_I_qprinterinfo.cpp
(qprinterinfo.cpp:163)
==22123==by 0x4010732: call_init (dl-init.c:72)
==22123==by 0x4010732: _dl_init (dl-init.c:119)
==22123==by 0x40151FE: dl_open_worker (dl-open.c:522)
==22123==by 0x4FA32DE: _dl_catch_exception (dl-error-skeleton.c:196)
==22123==by 0x40147C9: _dl_open (dl-open.c:605)
==22123==by 0x544CF95: dlopen_doit (dlopen.c:66)
==22123==by 0x4FA32DE: _dl_catch_exception (dl-error-skeleton.c:196)
==22123==by 0x4FA336E: _dl_catch_error (dl-error-skeleton.c:215)
==22123==by 0x544D734: _dlerror_run (dlerror.c:162)
==22123==by 0x544D050: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==22123==by 0x5F7DBC: _PyImport_FindSharedFuncptr (in
/usr/bin/python3.6)
==22123==by 0x5FB027: _PyImport_LoadDynamicModuleWithSpec (in
/usr/bin/python3.6)
==22123==
==22123== HEAP SUMMARY:
==22123== in use at exit: 5,615,552 bytes in 7,555 blocks
==22123==   total heap usage: 25,234 allocs, 17,679 frees, 48,677,061 bytes
allocated
==22123==
==22123== LEAK SUMMARY:
==22123==definitely lost: 157,672 bytes in 86 blocks
==22123==indirectly lost: 0 bytes in 0 blocks
==22123==  possibly lost: 230,559 bytes in 220 blocks
==22123==still reachable: 5,227,321 bytes in 7,249 blocks
==22123==   of which reachable via heuristic:
==22123== newarray   : 1,536 bytes in 16
blocks
==22123== suppressed: 0 bytes in 0 blocks
==22123== Rerun with --leak-check=full to see details of leaked memory
==22123==
==22123== For counts of detected and suppressed errors, rerun with: -v
==22123== Use --track-origins=yes to see where uninitialised values come
from
==22123== ERROR SUMMARY: 11565 errors from 209 contexts (suppressed: 0 from
0)
Segmentation fault

On Sun, Apr 26, 2020 at 9:27 PM Vasil Velichkov 
wrote:

> Hi Joe,
>
> On 26/04/2020 14.01, Joe D wrote:
> > Attached a valgrind log
>
> >> root@ubuntu-srv-10:/Applications/gnuradio/build/gr-qtgui/python/qtgui#
> valgrind -v ctest -V -R qa_qtgui
>
> You can't run this test under valgrind like this. You need to open
> ./build/gr-qtgui/python/qtgui/qa_qtgui_test.sh and on the last line add
> valgrind in front of python3. Something like:
>
> valgrind /usr/bin/python3 -B
> /Applications/gnuradio/gr-qtgui/python/qtgui/qa_qtgui.py
>
> Similarly you can run it under gdb in order to get a full backtrace of
> this segfault.
>
> Regards,
> Vasil
>
<>

Re: Release 3.8.1 on ubuntu 18.04 qa_qtgui (Failed) with Segmentation fault

[Vasil Velichkov]

Hi Joe,

On 26/04/2020 14.01, Joe D wrote:
> Attached a valgrind log

>> root@ubuntu-srv-10:/Applications/gnuradio/build/gr-qtgui/python/qtgui# 
>> valgrind -v ctest -V -R qa_qtgui

You can't run this test under valgrind like this. You need to open 
./build/gr-qtgui/python/qtgui/qa_qtgui_test.sh and on the last line add 
valgrind in front of python3. Something like:

valgrind /usr/bin/python3 -B 
/Applications/gnuradio/gr-qtgui/python/qtgui/qa_qtgui.py 

Similarly you can run it under gdb in order to get a full backtrace of this 
segfault.

Regards,
Vasil

Release 3.8.1 on ubuntu 18.04 qa_qtgui (Failed) with Segmentation fault

[Joe D]

Hello GNURadio’ers

Release 3.8.1  installed from source on ubuntu 18.04 qa_qtgui (Failed) with
Segmentation fault as below
(It was run on a native X server access Terminal )

testing with xvfb-run ctest -V -R qa_qtgui ends with Segmentation fault as
well

349/365 Testing: qa_qtgui
349/365 Test: qa_qtgui
Command: "/bin/sh"
"/Applications/gnuradio/build/gr-qtgui/python/qtgui/qa_qtgui_test.sh"
Directory: /Applications/gnuradio/build/gr-qtgui/python/qtgui
"qa_qtgui" start time: Apr 26 16:58 AEST
Output:
--
Segmentation fault (core dumped)

Test time =   0.83 sec
--
Test Failed.
"qa_qtgui" end time: Apr 26 16:58 AEST
"qa_qtgui" time elapsed: 00:00:00
--

Practically , cannot use any QT instrumentation block in GRC as it crashes
GRC with Segmentation fault

Attached a valgrind log

Thanks!
Joe

root@ubuntu-srv-10:/Applications/gnuradio/build/gr-qtgui/python/qtgui# 
root@ubuntu-srv-10:/Applications/gnuradio/build/gr-qtgui/python/qtgui# valgrind 
-v ctest -V -R qa_qtgui
==21388== Memcheck, a memory error detector
==21388== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==21388== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==21388== Command: ctest -V -R qa_qtgui
==21388== 
--21388-- Valgrind options:
--21388---v
--21388-- Contents of /proc/version:
--21388--   Linux version 4.15.0-96-generic (buildd@lgw01-amd64-004) (gcc 
version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)) #97-Ubuntu SMP Wed Apr 1 03:25:46 
UTC 2020
--21388-- 
--21388-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx
--21388-- Page sizes: currently 4096, max supported 4096
--21388-- Valgrind library directory: /usr/lib/valgrind
--21388-- Reading syms from /usr/local/bin/ctest
--21388-- Reading syms from /lib/x86_64-linux-gnu/ld-2.27.so
--21388--   Considering /lib/x86_64-linux-gnu/ld-2.27.so ..
--21388--   .. CRC mismatch (computed 1b7c895e wanted 2943108a)
--21388--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.27.so ..
--21388--   .. CRC is valid
--21388-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--21388--   Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--21388--   .. CRC mismatch (computed 41ddb025 wanted 9972f546)
--21388--object doesn't have a symbol table
--21388--object doesn't have a dynamic symbol table
--21388-- Scheduler: using generic scheduler lock implementation.
--21388-- Reading suppressions file: /usr/lib/valgrind/default.supp
==21388== embedded gdbserver: reading from 
/tmp/vgdb-pipe-from-vgdb-to-21388-by-root-on-???
==21388== embedded gdbserver: writing to   
/tmp/vgdb-pipe-to-vgdb-from-21388-by-root-on-???
==21388== embedded gdbserver: shared mem   
/tmp/vgdb-pipe-shared-mem-vgdb-21388-by-root-on-???
==21388== 
==21388== TO CONTROL THIS PROCESS USING vgdb (which you probably
==21388== don't want to do, unless you know exactly what you're doing,
==21388== or are doing some strange experiment):
==21388==   /usr/lib/valgrind/../../bin/vgdb --pid=21388 ...command...
==21388== 
==21388== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==21388==   /path/to/gdb ctest
==21388== and then give GDB the following command
==21388==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=21388
==21388== --pid is optional if only one valgrind process is running
==21388== 
--21388-- REDIR: 0x401f2f0 (ld-linux-x86-64.so.2:strlen) redirected to 
0x580608c1 (???)
--21388-- REDIR: 0x401f0d0 (ld-linux-x86-64.so.2:index) redirected to 
0x580608db (???)
--21388-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--21388--   Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--21388--   .. CRC mismatch (computed 50df1b30 wanted 4800a4cf)
--21388--object doesn't have a symbol table
--21388-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--21388--   Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--21388--   .. CRC mismatch (computed f893b962 wanted 95ee359e)
--21388--object doesn't have a symbol table
==21388== WARNING: new redirection conflicts with existing -- ignoring it
--21388-- old: 0x0401f2f0 (strlen  ) R-> (.0) 0x580608c1 ???
--21388-- new: 0x0401f2f0 (strlen  ) R-> (2007.0) 0x04c32db0 
strlen
--21388-- REDIR: 0x401d360 (ld-linux-x86-64.so.2:strcmp) redirected to 
0x4c33ee0 (strcmp)
--21388-- REDIR: 0x401f830 (ld-linux-x86-64.so.2:mempcpy) redirected to 
0x4c374f0 (mempcpy)
--21388-- Reading syms from /lib/x86_64-linux-gnu/librt-2.27.so
--21388--   Considering /lib/x86_64-linux-gnu/librt-2.27.so ..
--21388--   .. CRC mismatch (computed 16979484 wanted f9e041e3)
--21388--   Considering /usr/lib/debug/lib/x86_64-linux-gnu/librt-2.27.so ..
--21388--   .. CRC is valid
--21388-- Reading syms from /lib/x86_64-linux-gnu/libpthread-2.27.so
--21388--   Considering 

Re: Weird Python Sinks Crash with GNU Radio 3.8.1

[Gilad Beeri (ApolloShield)]

Hi,
I succeeded in narrowing down the flowgraph to a minimal graph that
reproduces the issue. You can see the Python file attached.

Basically, when having a file source that feeds 2 different Null Python
Sinks", the process crashes with a seg fault, with the same stack trace I
showed before:

*include/gnuradio/py_feval.h:69* which is *py_eval_ll::calleval(int)*:
*return eval(x);*

The flowgraph is very simple:
File Source -> Python Null Sink - 2 times

Replacing one of the Null Python Sinks to a standard Null Sink "solves" the
issue - the crash doesn't reproduce. You can comment-in line 43 and
comment-out line 44 to witness that.
I used the same file source block but I also tested it with 2 different
file sources and it behaves the same.

Any ideas why does this happen in GNU Radio 3.8.1?

ᐧ

On Thu, Apr 23, 2020 at 6:50 PM Gilad Beeri (ApolloShield) <
gi...@apolloshield.com> wrote:

> I have a rather complex flowgraph that used to work well with GNU Radio
> 3.7.
> I upgraded to 3.8.1, and now it crashes (for some input, but even when I
> use /dev/zero as file source) with something that looks like in the core of
> GNU Radio (not directly in the block).
>
> Environment:
> GNU Radio 3.8.1
> Python 3.8.2
> Ubuntu 16.04.6
>
> There are many blocks, but let's focus on the last ones.
> I have a float-to-int block (the standard one) which feeds data into a
> sink block that is written in Python. In case it is relevant, this is the
> block that feeds the sink: *float_to_int =
> blocks.float_to_int(); self.connect(float_to_int, sink)*
>
> The process crashes with a segmentation fault.
>
> If I nullify the Python sink (commenting out all real processing code in
> work()), the issue still happens.
> Furthermore, I wrote a "my_null_sink" block in Python (see code below). It
> still crashes with the same issue (after I connected it to the float-to-int
> output instead of the original Python sink).
> When I replace "my_null_sink" with GNU Radio's standard Null Sink, it
> doesn't crash anymore.
> Using the same input file and my_null_sink, it crashes about 95% of the
> runs (i.e., not 100%, but almost always), with Null Sink, 0%.
> That's why I believe it is something with the Python binding. I do have
> other Python blocks in the flowgraph (one that is connected to the file
> source and does some simple processing before passing forward the samples).
>
> When I run it with gdb, I catch the exception and the stack trace is below.
> The 2nd frame in the stack sends us to *block_gateway_impl.cc:139*,
> work(),
> *_handler->calleval(0);*
> The 1st stack frame doesn't have an associated module for the specified
> address (0x02324b90 in ??), "i sh" shows it isn't associated with
> any module, and "info symbol " confirms this. I also witness that all
> modules are loaded into addresses > 0x7f13, so I assume the
> address from the stack trace is really not a valid library, but some
> garbage (it's also very close to 0).
> The faulty memory address tends to change which is another indication for
> garbage.
>
> Note: when I build the app in Debug, another stack frame appears between
> the one that isn't associated with a module, to the one in
> block_gateway_impl:
> *include/gnuradio/py_feval.h:69* which is *py_eval_ll::calleval(int)*:
> *return eval(x);*
>
> When I implement the simplest flowgraph: File Source with /dev/zero ->
> Throttle -> my_null_sink, it doesn't crash.
>
> In the original flowgraph, I disabled almost all blocks, and specifically,
> I did not leave any enabled own C++ block - just to rule out the
> possibility that one of the blocks corrupts the memory. It didn't change
> anything.
>
> I tested it on another machine with a similar setup (GNU Radio 3.8.1) and
> it reproduced. On an older machine, still with GNU Radio 3.7.11.1, it works
> (doesn't crash).
>
> Any ideas will be appreciated.
> --
>
> *my_null_sink.py*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *import numpyfrom gnuradio import grclass my_null_sink(gr.sync_block):
> def __init__(self):gr.sync_block.__init__(self,
> name="my_null_sink",in_sig=[numpy.int32],
> out_sig=None)print('* my_null_sink init')def work(self,
> input_items, output_items):return len(input_items[0])*
>
>
> *Exception in GDB*
>
>
> *Thread 20 "my_null_sink25" received signal SIGSEGV, Segmentation fault*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *#0  0x02324b90 in ?? ()#1  0x7f5ec43df433 in
> gr::block_gateway_impl::work (this=this@entry=0x2324fc0, noutput_items=8,
>   input_items=std::vector of length 1, capacity 1 = {...},
> output_items=std::vector of length 0, capacity 0)at
> /home/user/gr/src/gnuradio/gnuradio-runtime/lib/block_gateway_impl.cc:139#2
>  0x7f5ec43df471 in gr::block_gateway_impl::general_work
> (this=0x2324fc0, noutput_items=, ninput_items=...,
> input_items=std::vector of length 1, capacity 1 = {...}, output_items=...)
>   at
>