Gdb help

Hi

I’m trying to debug an application using gdb. I used the segment of
code in the how to write your own blocks page to print out the process
id and attach gdb to it. When I try to set breakpoints, I get a
message saying

No line 110 in file ‘’…/Modules/python.c’’

Also, when I run the Python app, gdb tells me that the program has
been started already. And and asks if it should start the program
from the beginning. Choosing yes causes gdb to run the Python
interpreter itself. Choosing no doesn’t do anything.

Can anyone please help me with this?

Thank you in advance.

Sebastiaan


Sebastiaan H.
Radar and Remote Sensing Group, University of Cape Town
Tel: +27 83 305 5667

On Thu, Jan 08, 2009 at 10:17:31AM +0200, Sebastiaan H. wrote:

Hi

I’m trying to debug an application using gdb. I used the segment of
code in the how to write your own blocks page to print out the process
id and attach gdb to it. When I try to set breakpoints, I get a
message saying

No line 110 in file ‘’…/Modules/python.c’’

Also, when I run the Python app, gdb tells me that the program has
been started already.

It has already started, you used the “attach” command to attach to a
running program :slight_smile: Tell it to continue with the “c” command.

When it segfaults get a backtrace using

bt

or

thread apply all bt

And and asks if it should start the program
from the beginning. Choosing yes causes gdb to run the Python
interpreter itself. Choosing no doesn’t do anything.

Can anyone please help me with this?
Thank you in advance.

Sebastiaan

gdb has a nice manual…

Eric

Eric

Sorry about previously. I guess I need to read more :). I got the
gdb backtrace.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7dc18c0 (LWP 7143)]
PyErr_Restore (type=0x81422c0, value=0x8e36ac8, traceback=0x0)
at …/Python/errors.c:39
39 …/Python/errors.c: No such file or directory.
in …/Python/errors.c
(gdb) bt
#0 PyErr_Restore (type=0x81422c0, value=0x8e36ac8, traceback=0x0)
at …/Python/errors.c:39
#1 0x080d9e6e in PyErr_SetString (exception=0x81422c0,
string=0x8ffebac “vector_to_streams(13): missing connection from
output port 0”) at …/Python/errors.c:57
#2 0xb5ffb5fa in SWIG_Python_SetErrorMsg ()
from
/usr/local/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so
#3 0xb600bdf0 in _wrap_top_block_run_unlocked ()
from
/usr/local/lib/python2.5/site-packages/gnuradio/gr/_gnuradio_swig_py_runtime.so
#4 0x0805cb97 in PyObject_Call (func=0x0, arg=0x8e0ca4c, kw=0x0)
at …/Objects/abstract.c:1861
#5 0x080c7e04 in PyEval_EvalFrameEx (f=0x8fdb054, throwflag=0)
at …/Python/ceval.c:3853
#6 0x080cb1f7 in PyEval_EvalCodeEx (co=0x8780e30, globals=0x870c13c,
locals=0x0, args=0x8fdb03c, argcount=1, kws=0x8fdb040, kwcount=0,
defs=0x0, defcount=0, closure=0x0) at …/Python/ceval.c:2836
#7 0x080c93fe in PyEval_EvalFrameEx (f=0x8fdaefc, throwflag=0)
at …/Python/ceval.c:3669
#8 0x080c96e5 in PyEval_EvalFrameEx (f=0x81770d4, throwflag=0)
at …/Python/ceval.c:3659
#9 0x080cb1f7 in PyEval_EvalCodeEx (co=0xb7d4f260, globals=0xb7d9aacc,
—Type to continue, or q to quit—
locals=0xb7d9aacc, args=0x0, argcount=0, kws=0x0, kwcount=0,
defs=0x0,
defcount=0, closure=0x0) at …/Python/ceval.c:2836
#10 0x080cb347 in PyEval_EvalCode (co=0xb7d4f260, globals=0xb7d9aacc,
locals=0xb7d9aacc) at …/Python/ceval.c:494
#11 0x080ea818 in PyRun_FileExFlags (fp=0x816b008,
filename=0xbf93b68a “test_channelise.py”, start=257,
globals=0xb7d9aacc,
locals=0xb7d9aacc, closeit=1, flags=0xbf93a5a8)
at …/Python/pythonrun.c:1273
#12 0x080eaab9 in PyRun_SimpleFileExFlags (fp=0x816b008,
filename=0xbf93b68a “test_channelise.py”, closeit=1,
flags=0xbf93a5a8)
at …/Python/pythonrun.c:879
#13 0x08059335 in Py_Main (argc=1, argv=0xbf93a674) at
…/Modules/main.c:523
#14 0x080587f2 in main (argc=Cannot access memory at address 0x0
) at …/Modules/python.c:23

Sebastiaan

Eric

I think the unconnected output port is because I need to first connect
the filterbank to the USRP and then connect one of the channels to
whatever I want to do with it. The code breaks in either the
self.connect(self.u,pfb) or the
self.connect((pfb,5),self.guts,self.volume_control,audio_sink) line.
I suspect that it is the former.

pfb = blks2.analysis_filterbank(20,taps)

#End PFB

print “Done init”

self.connect(self.u,pfb)

print “Done connect(self.u,pfb)”

self.connect((pfb,5),self.guts,self.volume_control,audio_sink)

I ran gdb again. The “Done connect(self.u,pfb)” displays before the
program breaks. When I remove the
self.connect((pfb,5),self.guts,self.volume_control,audio_sink), the
same thing happens.

Sebastiaan

On Fri, Jan 09, 2009 at 09:42:59AM +0200, Sebastiaan H. wrote:

Eric

Sorry about previously. I guess I need to read more :). I got the
gdb backtrace.

This looks suspicious:

string=0x8ffebac “vector_to_streams(13): missing connection from
output port 0”) at …/Python/errors.c:57

I’m guessing there’s an error in your program that’s triggering a bug
in the GR code.

The complaint indicates a gr.vector_to_streams block doesn’t have
anything connected to it’s first output port. Does that sound
possible? Of course the code shouldn’t die…

If fixing a problem in your code (missing connection?) makes the
problem go away, can you please see if you can create a small test
case that reproduces the problem? That way we can go after the GR bug.

Thanks!
Eric

On Fri, Jan 9, 2009 at 2:34 AM, Sebastiaan H. [email protected]
wrote:

I think the unconnected output port is because I need to first connect
the filterbank to the USRP and then connect one of the channels to
whatever I want to do with it. The code breaks in either the
self.connect(self.u,pfb) or the
self.connect((pfb,5),self.guts,self.volume_control,audio_sink) line.
I suspect that it is the former.

What I think is happening is two-fold. First, you need to have all
the outputs of the filterbank connected to something, or you end up
with an invalid topology. This causes an C++ exception to occur.
Normally, this gets translated into a Python traceback and you get
some sensible output. However, we’ve been battling a bug for sometime
now that keeps creeping back in, where C++ exceptions don’t propagate
back up to Python and instead you get a segfault or abort.

If you have output #5 of pfb connected, then outputs 0-4 need to be
connected also. gr.null_sink(gr.sizeof_gr_complex) would be fine
here.

To change which channel is being output, in your code, you call lock()
on the flowgraph/topblock object, call disconnect(…) for the
connection between the pfb output and the self.guts block,
disconnect() again for the new pfb output and the null sink, then
reconnect in the opposite sense. Finally, call unlock(), which will
“recompile” the flowgraph and restart the scheduler.

-Johnathan

-Johnathan