(crush) debugging with gdb - infinit loop problem

[DoMeN]

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:

Code

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

[mandrav]

Will have a look into it.

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?

Go into your window manager's shortcuts configuration and remove the Alt+F7 shortcut from whatever it is bound to. C::B never receives this keystroke because your window manager receives and handles it first.

[Pecan]

This patch will most probable aleviate the CB crash when using the stop button.

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1881&group_id=5358
Fix for Debugger termination crashes

This patch will allow a Linux/Unix user to use console I/O and trace console programs under the CB debugger.

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1882&group_id=5358
Debugging Console for Linux

[DoMeN]

Great thanks for the info. I'll check it out.

Domen

[raph]

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1881&group_id=5358
Fix for Debugger termination crashes

Thx alot, debugger crashes often, here :?

[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

[Pecan]

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

Code

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

[Pecan]

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

Code

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

[DoMeN]

Sorry  Ment svn sources.

[DoMeN]

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

[DoMeN]

I tryed with changing the code to use windows style of killing gdb insetad of linux style and I don't experience any crashes. Don't know why. I gues that there must be something wrong with pid variable since windows part of the code uses m_Pid instead and works OK.

I think that it would be better if this difference between linux and windows part would be removed and only win src would stay. Should I do this and commit a patch to BerilOS?

r. Domen

[Pecan]

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

Code

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.

[DoMeN]

Oh I see,

I only applied patch 1881 as the console patch is only intended for linux use and I'd like to have the same source for windows as well without aditional differences in what is implemented. I didn't know that it is necessary to apply both of the patches to fix gdb crush bug. I'll test it.

r. Domen

[DoMeN]

BTW when has the patch No. 1882 been changed?

This part is now missing.

@@ -1521,7 +1550,8 @@
                     _("Debug"), wxOK | wxICON_EXCLAMATION);
             else
         #endif
-            wxKill(pid, wxSIGINT);
+            if (pid > 0)
+                wxKill(pid, wxSIGINT);
         #else
             m_pProcess->CloseOutput();
             wxKillError err = m_pProcess->Kill(m_Pid, wxSIGKILL);

Was it applied to patch 1880?

r. Domen

[DoMeN]

I've built the latest svn version that is already patched and the patch doesn't solve the problem. It is true that C::B doesn't crush but now you get an error message that debugging process can not be stopped and you can't get out of the debugging session unles you close C::B or at least the entire workspace. Could this be changed to Error message with ok and force quit button?

Domen

EDIT: Closing the project doesn't stop the debugging session. When you reopen the project the debugging session is stil  up and running. I doubt that this is a desired behaviour of C::B.