discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] GNURadio segmentation fault


From: John Shields
Subject: Re: [Discuss-gnuradio] GNURadio segmentation fault
Date: Sun, 22 May 2016 18:10:14 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

On 22/05/16 11:06, Marcus D. Leech wrote:
On 05/22/2016 05:19 AM, Marcus Müller wrote:
Hi John,

I don't really know about the memory usage you see, but:
Did you rebuild GNU Radio (and UHD and basically everything you did not
install directly through Ubuntu's apt-get)? Upgrading a distro often
changes the libc version used, and that might mean that the ABI of the
very core functionality has changed, and your program is calling
functions with the wrong parameters or functions that don't exist.

That would be my first guess.
Now, you said you upgraded in an attempt to remedy those failures, so
I'm fully aware that might not be the /right/ guess, but segfaults in
libc usually only happen if you call some system functionality with a
non-existing / too short buffer or invalid pointer to a structure or
something like that, and the most common cause for that (aside from
actual bugs, but I'm not aware of anything currently, but I haven't
really used simple_ra much) would be an ABI mismatch. Now, this isn't
going to fix if something in simple_ra actually segfaults:

So, my first attempt would really be a make clean; make; (sudo) make
install .
If that fails, run your simple_ra application through GDB. The trick
here would probably be (Marcus L., you shout if I say something stupid,
right?) to modify the simple_ra script; at the very end, replace

simple_ra_receiver.py --frequency ...

by

gdb -ex run --args python2 simple_ra_receiver --frequency ...

to let gdb run the python flow graph for you. Then, at some point gdb
should catch the segfault and drop you to a command prompt; "bt" or
"backtrace" is the command you want to do to see the cascade of calls
going on (it might be helpful to have installed the "xyz-dbg" packages
for Ubuntu's python and libc packages, and build your GNU Radio with
debug symbols enabled, i.e. using -DCMAKE_BUILD_TYPE=RelWithDebInfo when
calling cmake) when the segfault happened. Often, that's already
sufficient to narrow down the bug. If it isn't: the lines of the
backtrace start with a #number; that number is the frame number, and you
can change into each frame, do a "list" (if debug symbols are present)
and get the source code where the program currently is, use "print" to
print variables (really invaluable if you've e.g. got a "for" loop that
keeps on writing past the end of a buffer and you don't know why).

Best regards,
Marcus


It's conceivable that this is simple_ra's fault. While it's almost-entirely written in GRC with some helper Python, there are some custom blocks used from gr-ra_blocks, written in C++. I'd be interested to know if the failure is actually from one of those...



_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Thank you Marcus'.

I used Marcus(L) build script to get UHD/GNURadio so I will do the :make clean etc. that is suggested. You can see from the syslog that, the upgrade to 15.10 did, indeed, bump the revision of libc.

That was a good tip re: modifying the simple_ra run script to put GDB in first.

Will run in that mode and let you know what I get.

           Kind Regards,

                     John



reply via email to

[Prev in Thread] Current Thread [Next in Thread]