[Discuss-gnuradio] Re: debugging

[Lee Patton]

Eric -

I've attached the gdb back trace you asked for.

Also, I used pdb in an attempt to debug the python code.  I found:

1) usrp_oscope.py: 
     * app.Mainloop() never returns (you could have guessed that)

2) stdgui.py:  
     * self.Destroy() in the OnCloseWindow method does return
     * put a pdb.set_trace() after the self.Destroy() call
     * can step through code until reach line 1722 of _gdi.py

3) site-packages/wx-2.6-gtk2-ansi/wx/_gdi.py:
     * Segmentation Fault (core dumped) when attempt next step

1722 ->     def __del__(self, destroy=_gdi_.delete_Font):
1723            """__del__(self)"""
1724            try:
1725                if self.thisown: destroy(self)
1726            except: pass
1727
(Pdb) l
1728        def Ok(*args, **kwargs):
1729            """
1730            Ok(self) -> bool
1731
1732            Returns ``True`` if this font was successfully created.
1733            """
1734            return _gdi_.Font_Ok(*args, **kwargs)
1735
1736        def __nonzero__(self): return self.Ok()
1737        def __eq__(*args, **kwargs):
1738            """__eq__(self, Font other) -> bool"""
(Pdb) s


Well, I'm not much help from this point forward. Hopefully, that gives
you something to work with.

- Lee


On Thu, 2005-10-27 at 19:15 -0700, Eric Blossom wrote:
> 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
> 
>

log.dbg
Description: Text document