Hi.
I've noticed a problem with C::B and gdb when you debug a program that enters an infinit loop or waits for some HW input.
Simple example:
int main (int args, char *argv[]) {
while (1) {
}
}
This program will go into an infinit loop and the only option you have is to press "stop debugging" button and when you do this C::B crushes.
In such a small program this is no problem (except that you get anoyed because you have to reopen everything :() but in a large program that has an wait_for_com_port_input(); function or something like that where the program goes in to an infinit loop it is a problem even to find the place where C::B crushes.
I don't know how the crush when pressed "stop debugging" button in this case could be fixed but it would be great to have a "pause" button that would send "ctrl+c" command to gdb (if running gdb from console this would stall the program where it is at the moment and you would regain the control over gdb) and if gdb would be reachable again I think that C::B would continue execution as if it had reached a breakpoint.
Unfortunately I don't have any experience with wxWidgets programming so I don't know how "ctrl+c" could be simulated and my debug plugin src knowladge is also werry limited.
Could someone write a patch for this or at least help me a bit with how I could make such a patch myself (solution suggestions, info about debug plugin (where the code for debugging buttons actions is located) and simulating ctrl+c command).
BTW I also noticed the problem with alt+F7 shortcut in Linux Debian Edge. The debug plugin doesn't intercept it and executes Linux shortcut that is set for this key combination. Is this C::B or wxWidgets and Linux problem?
r. DoMeN
http://developer.berlios.de/patch/?func=detailpatch&patch_id=1881&group_id=5358
Fix for Debugger termination crashes
I've tested this patch on Debian Etch with C::B nightly 3656 and two of other older versions. It doesn't fix the problem of crushing if program ends. I'm using a modified gdb but I doubt that this makes any difference in this case (but I'm not 100% shore :) ). Was this patch ment for "if program ends with execution and you click on stop button then it won't crush" or for "if program is still executing but is in an infinit loop then it won't crush when stop button is clicked" ? I am debugging firmvare programs so they never stop executing (they go in an infinit loop after return 0; in main function). Could this be causing crushes?
Domen
The fix is intended to stop a crash when CB frees its gdb message parser while the parser is still processing output messages.
Your situation may be causing a different crash.
I don't even know how you get the stop button to stop on your example. I had to use killall to get CB to stop the debugger.
There's another bug in debuggergdb that always considers gdb to be in the "stopped" condition when a breakpoint was never set. So it will not stop an infinite loop that never had a breakpoint set.
But, if I set a breakpoint on the "while (1)", start the debugger, get the trap, clear the breakpoint, continue the loop; I can hit the stop button twice to stop the program. It crashes without the fix, but stops ok with the fix.
This is with:
Debugger name and version: GNU gdb 6.4.90-debian
Breakpoint 1, main (args=1, argv=0xbfa0f424) at /home/pecan/proj/temp/test/main.cpp:8
/home/pecan/proj/temp/test/main.cpp:8:114:beg:0x804839c
>>>>>>cb_gdb:
> info program
Using the running image of child process 1652.
Program stopped at 0x804839c.
It stopped at breakpoint 1.
It stopped at a breakpoint that has since been deleted.
Type "info stack" or "info registers" for more information.
>>>>>>cb_gdb:
> cont
Breakpoint 1, main (args=1, argv=0xbfa0f424) at /home/pecan/proj/temp/test/main.cpp:8
/home/pecan/proj/temp/test/main.cpp:8:114:beg:0x804839c
>>>>>>cb_gdb:
> delete breakpoints 1
>>>>>>cb_gdb:
> cont
Program received signal SIGINT, Interrupt.
main (args=1, argv=0xbfa0f424) at /home/pecan/proj/temp/test/main.cpp:8
/home/pecan/proj/temp/test/main.cpp:8:114:beg:0x804839c
>>>>>>cb_gdb:
> quit
Hangup detected on fd 0
error detected on stdin
ParseOutput() closed m_State.Driver
http://developer.berlios.de/patch/?func=detailpatch&patch_id=1881&group_id=5358
Fix for Debugger termination crashes
I've tested this patch on Debian Etch with C::B nightly 3656 and two of other older versions. It doesn't fix the problem of crushing if program ends. I'm using a modified gdb but I doubt that this makes any difference in this case (but I'm not 100% shore :) ). Was this patch ment for "if program ends with execution and you click on stop button then it won't crush" or for "if program is still executing but is in an infinit loop then it won't crush when stop button is clicked" ? I am debugging firmvare programs so they never stop executing (they go in an infinit loop after return 0; in main function). Could this be causing crushes?
Domen
I've tested this patch on Debian Etch with C::B nightly 3656 and two of other older versions.
What do you main by "Nightly". The patch is meant for SVN sources. You cannot apply a patch to a Nightly. They're binary.
The fix is intended to stop a crash when the stop button is hit while the program is executing an I/O operation or in a loop, CB frees its gdb message parser while the parser is still processing gdb output messages.
Your situation may be causing a different crash.
I don't even know how you get the stop button to stop on your loop example. I had to use killall to stop the debuggee because CB would not stop the debugger.
There's another bug in debuggergdb that always considers gdb to be in the "stopped" condition when a breakpoint was never set. So the stop button will not stop an infinite loop that never had a breakpoint set.
But, if I set a breakpoint on the "while (1)", start the debugger, get the trap, clear the breakpoint, continue the loop; I can hit the stop button twice to stop the program. It crashes without the fix, but stops ok with the fix.
This is with:
Debugger name and version: GNU gdb 6.4.90-debian
Breakpoint 1, main (args=1, argv=0xbfa0f424) at /home/pecan/proj/temp/test/main.cpp:8
/home/pecan/proj/temp/test/main.cpp:8:114:beg:0x804839c
>>>>>>cb_gdb:
> info program
Using the running image of child process 1652.
Program stopped at 0x804839c.
It stopped at breakpoint 1.
It stopped at a breakpoint that has since been deleted.
Type "info stack" or "info registers" for more information.
>>>>>>cb_gdb:
> cont
Breakpoint 1, main (args=1, argv=0xbfa0f424) at /home/pecan/proj/temp/test/main.cpp:8
/home/pecan/proj/temp/test/main.cpp:8:114:beg:0x804839c
>>>>>>cb_gdb:
> delete breakpoints 1
>>>>>>cb_gdb:
> cont
Program received signal SIGINT, Interrupt.
main (args=1, argv=0xbfa0f424) at /home/pecan/proj/temp/test/main.cpp:8
/home/pecan/proj/temp/test/main.cpp:8:114:beg:0x804839c
>>>>>>cb_gdb:
> quit
Hangup detected on fd 0
error detected on stdin
ParseOutput() closed m_State.Driver
I experience a crush in debuggergdb.cpp: void DebuggerGDB::Stop() in this line -> wxKill(pid, wxSIGINT);
Is this a wxWidgets function or is it a c::b function? I can't find its body so I gues this is wxWidgets stuff. How can I debug this?
r. Domen
If my fix was applied correctly, that line should read
If (pid > 0)
wxKill(pid, wxSIGINT);
The wxKill is killing codeblocks itself under some conditions because the pid is not checked.
Make sure the "if (pid > 0)" is there.