> 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
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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment