How do I "interrupt" a running program to get back into the debugger (without actually signaling the program/otherwise affecting the execution)? Currently, when I hit ctrl-c, I think this actually sends SIGINT to the program, which is not what I want.
I read through the signaling section of the docs, and it says that I can hook the "stop" action into SIGINT (which, according to my "info handle" output, seems to be the default):
Signal Stop Print Print Stack Pass to program
SIGINT True True False False
When I hit ctrl-c, I see:
Program received signal SIGINT
Indeed I'm back at the debugger, but I basically interrupted a system call (select.select()).
Any hints? Thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If don't understand you are asking for. If you want to *asynchronously* indicate that you want to enter the debugger, you need a way to *asynchronously* send a message to your program. In a Unixy environment that's what "kill" does via a signal handling mechanism. The only alternative I can think of is having your program set up a thread which is waiting on an I/O event. And although you could enter the debugger for that thread, right now there's no automatic provision that it will cause other threads to get stopped or traced. (It's possible a future version of pydb will be able to do this to a limited extent though.)
If you don't need the asynchronous behavior, then the pydb documentation describes how to call the debugger from inside your program.
As for not altering the program (or program's behavior) but having it go into the debugger? I'm not sure this is possible in general. In practice it seems to do what I expect it to do. Strictly speaking, entering the debugger *is* altering your program. Even without the debugger, if you send a signal to the program and it was in the middle of a "sleep" command, that command is terminated - you don't go back into the middle of the sleep. If you write a thread that handles I/O for such a signal, well, it has to get that message back to the other threads and that has to somehow change the behavior.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How do I "interrupt" a running program to get back into the debugger (without actually signaling the program/otherwise affecting the execution)? Currently, when I hit ctrl-c, I think this actually sends SIGINT to the program, which is not what I want.
I read through the signaling section of the docs, and it says that I can hook the "stop" action into SIGINT (which, according to my "info handle" output, seems to be the default):
Signal Stop Print Print Stack Pass to program
SIGINT True True False False
When I hit ctrl-c, I see:
Program received signal SIGINT
Indeed I'm back at the debugger, but I basically interrupted a system call (select.select()).
Any hints? Thanks in advance.
If don't understand you are asking for. If you want to *asynchronously* indicate that you want to enter the debugger, you need a way to *asynchronously* send a message to your program. In a Unixy environment that's what "kill" does via a signal handling mechanism. The only alternative I can think of is having your program set up a thread which is waiting on an I/O event. And although you could enter the debugger for that thread, right now there's no automatic provision that it will cause other threads to get stopped or traced. (It's possible a future version of pydb will be able to do this to a limited extent though.)
If you don't need the asynchronous behavior, then the pydb documentation describes how to call the debugger from inside your program.
As for not altering the program (or program's behavior) but having it go into the debugger? I'm not sure this is possible in general. In practice it seems to do what I expect it to do. Strictly speaking, entering the debugger *is* altering your program. Even without the debugger, if you send a signal to the program and it was in the middle of a "sleep" command, that command is terminated - you don't go back into the middle of the sleep. If you write a thread that handles I/O for such a signal, well, it has to get that message back to the other threads and that has to somehow change the behavior.