Version: CVS (13.11.2009) (using KDE 4.3.3) Compiler: g++ (Ubuntu 4.4.1-4ubuntu8) 4.4.1 OS: Linux Installed from: Ubuntu Packages When I set breakpoints before I start the program the debugger correctly stops at them. When I add them while the program is running the debugger doesn't stop. How to reproduce: I attached a test project: 1.) build it 2.) setup the executable in the project settings (for me it works only having an absolute path set, but this is a different issue) 3.) debug it 4.) add a breakpoint in the while loop. Expected Behaviour: The debugger should stop.
Created attachment 38300 [details] Testproject to reproduce bug
I forgot to mention the gdb version I'm using: gdb --version GNU gdb (GDB) 7.0-ubuntu
Just to make sure: I did not install kdevelop from ubuntu packages but built it from subverion today.
I can reproduce this here.
This was broken by r1022390. The comment there was: "Kill the s_appRunning state. For one thing, GDB in non-stop mode does not even have such a concept, as each thread can be run and stopped individually. Secondly, this is only used to display status messages, to a non-existent status bar." The second reason is not really the case however, because removing that state means the GDB debugger is never set to ActiveState or PausedState, which means that when KDevPlatform detects a new breakpoint added during one of those states, it won't notify GDB to add it. Due to that, it should probably be reverted, at least till there's something else in place that will set those states.
Thanks for analysis. Looking into this now.
Additional Bug: Debugger actions (run, step etc) are not correctly disabled when debugee is running. Would it be a good idea to have this state not per DebugSession but per thread?
btw, that additional bug is #213414
I am indeed thinking about making something -- not yet clear what -- track the state of each thread. For gdb all-stop mode, every thread will have the same state, while for gdb non-stop mode, when we support it, every thread might have different state. Then, the buttons will be enabled or disabled depending on whether the current thread is running or not. I'm still looking into implementation details.
fixed in rev. 1055240