> 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
No comments:
Post a Comment