pydb remote debugging/cmd.Cmd over socket?

Discussion in 'Python' started by Diez B. Roggisch, May 28, 2008.

  1. Hi,

    I'm fiddling around with pydb. Installation and usage are fine. What I
    especially like is the fact that you can attach a signal such that you drop
    into debugging mode on demand.

    But this is of limited use to me in situations where a server is written in
    python. According to the source, pydb's debugger class Gdb extends cmd.Cmd.

    It passes stdin/stdout-arguments that should be usable to replace the
    standard streams. But so far all my experiments simply dropped the process
    into debugging mode putting out and getting io over stdin/stdout - not my
    self-supplied streams.

    So I wonder (being a bit rusty on my UNIX-piping-skillz): how does one do
    that - essentially, create a remote python shell using cmd.Cmd?

    Diez
    Diez B. Roggisch, May 28, 2008
    #1
    1. Advertising

  2. Diez B. Roggisch

    R. Bernstein Guest

    "Diez B. Roggisch" <> writes:

    > Hi,
    >
    > I'm fiddling around with pydb. Installation and usage are fine. What I
    > especially like is the fact that you can attach a signal such that you drop
    > into debugging mode on demand.
    >
    > But this is of limited use to me in situations where a server is written in
    > python. According to the source, pydb's debugger class Gdb extends cmd.Cmd.
    >
    > It passes stdin/stdout-arguments that should be usable to replace the
    > standard streams. But so far all my experiments simply dropped the process
    > into debugging mode putting out and getting io over stdin/stdout - not my
    > self-supplied streams.
    >
    > So I wonder (being a bit rusty on my UNIX-piping-skillz): how does one do
    > that - essentially, create a remote python shell using cmd.Cmd?
    >
    > Diez


    As part of the 2006 Google Summer of Code project Matt Flemming
    started working on remote debugging in pydb. Alas it wasn't completed
    and I let the code fall through the cracks.

    Matt claimed it worked to some degree but I could never get it to work
    for me. Most definitely the code has atrophied.

    The user interface was loosely based or reminiscent of gdb. So
    you'd run pydbserver either as a command inside the debugger or as an
    option to pydb or call inside Python pdbserver after importing.

    There is a connection class (file pydb/connection.rb) which was to
    allow different kinds of protocols, like a socket connection or
    a serial line connection, or maybe even two FIFO's so that you could
    connect to a different process on the same computer.

    And there were some commands on the user-interaction side
    to attach or detach the Python program you want to debug.

    If you look in pydb.py.in and gdb.py.in you'll see some code commented
    out with double hashes which is part of this effort.

    I invite you or others to try to resurrect this effort. However as I
    look at the code now, it doesn't make much sense other than the broad
    outline given above.

    Another approach and possibly a much simpler one if you are looking
    for a Python debugger which supports remote debugging is Winpdb
    http://winpdb.org/ by Nir Aides.
    R. Bernstein, May 29, 2008
    #2
    1. Advertising

  3. > As part of the 2006 Google Summer of Code project Matt Flemming
    > started working on remote debugging in pydb. Alas it wasn't completed
    > and I let the code fall through the cracks.
    >
    > Matt claimed it worked to some degree but I could never get it to work
    > for me. Most definitely the code has atrophied.
    >
    > The user interface was loosely based or reminiscent of gdb. So
    > you'd run pydbserver either as a command inside the debugger or as an
    > option to pydb or call inside Python pdbserver after importing.
    >
    > There is a connection class (file pydb/connection.rb) which was to
    > allow different kinds of protocols, like a socket connection or
    > a serial line connection, or maybe even two FIFO's so that you could
    > connect to a different process on the same computer.
    >
    > And there were some commands on the user-interaction side
    > to attach or detach the Python program you want to debug.
    >
    > If you look in pydb.py.in and gdb.py.in you'll see some code commented
    > out with double hashes which is part of this effort.
    >
    > I invite you or others to try to resurrect this effort. However as I
    > look at the code now, it doesn't make much sense other than the broad
    > outline given above.


    Hm. Ok, I'll look into that. It's just that I don't get cmd.Cmd to work
    against two streams. Maybe I need to dive into unix-coding a bit deeper
    again.

    > Another approach and possibly a much simpler one if you are looking
    > for a Python debugger which supports remote debugging is Winpdb
    > http://winpdb.org/ by Nir Aides.



    I've found that - and while it's nice, it has one problem: I can only
    start it with winpdb governing the process already, preventing python
    from starting.

    In contrast, the possibility to use a sginal to start the debugger of
    pydb is great, so that's the reason I want to stick with it.

    Diez
    Diez B. Roggisch, May 29, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Rudin
    Replies:
    4
    Views:
    534
    Paul Rudin
    May 18, 2007
  2. R. Bernstein

    Possibly pydb 1.23 release around May 30

    R. Bernstein, May 21, 2008, in forum: Python
    Replies:
    0
    Views:
    248
    R. Bernstein
    May 21, 2008
  3. kj
    Replies:
    4
    Views:
    321
  4. R. Bernstein

    pydb 1.24

    R. Bernstein, Dec 10, 2008, in forum: Python
    Replies:
    2
    Views:
    316
    R. Bernstein
    Dec 12, 2008
  5. jcervidae
    Replies:
    1
    Views:
    272
    Diez B. Roggisch
    May 18, 2009
Loading...

Share This Page