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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio