discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]