[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Re: debugging
From: |
Eric Blossom |
Subject: |
[Discuss-gnuradio] Re: debugging |
Date: |
Thu, 27 Oct 2005 19:15:18 -0700 |
User-agent: |
Mutt/1.5.6i |
On Thu, Oct 27, 2005 at 09:14:18PM -0400, Lee Patton wrote:
>
> Anyone have any ideas why I'm seeing that core dump when I do a File-Exit?
>
I'm not sure, I see it too.
I'd appreciate it if someone would track it down with gdb.
To start we need a backtrace from where the problem occurs.
Use the "bt' gdb command.
Debugging with gdb
If your block isn't working, and you can't sort it out through
python test cases or a few printfs in the code, you may want to use
gdb to debug it. The trick of course is that all of GNU Radio,
including your new block, is dynamically loaded into python for
execution.
Try this: In your python test code, after the relevant imports,
print out the process id and wait for a keystroke. In another window
run gdb and tell it to attach to the python process with the given
process id. At this point you can set breakpoints or whatever in
your code. Go back to the python window and hit Enter so it'll
continue.
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import my_buggy_module
# insert this in your test code...
import os
print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)
raw_input ('Press Enter to continue: ')
# remainder of your test code follows...
Another SNAFU you might run into is that gdb 6.2 isn't able to set
breakpoints in the constructors or destructors generated by g++
3.4. In this case, insert a call to the nop function
gri_debugger_hook in the constructor and recompile. Load the code as
before and set a break point on gri_debugger_hook.
Eric
Re: [Discuss-gnuradio] "Failed to set initial frequency" and SDCC 2.5.0, Stephane Fillod, 2005/10/28