Community
Participate
Working Groups
Hi, I'm on a Linux system using Eclipse 3.1.1 with CDT 3.0. The problem is that when a program is being debugged and it's breakpoints are disabled during that debug session, the changes to the breakpoints are not propagated through when the program is "Restarted" (using the button in the Debug view). I'm attaching a very simple testcase - just a helloWorld. To reproduce the problem: 1. Import and build the attached helloWorld project. 2. Set a breakpoint at hello.c:6. 3. Create a debug session with the "Connect process input & output to a terminal" off. (This is necessary to bypass bug#37989). 4. Reach the breakpoint at hello.c:6. 5. Disable the breakpoint at hello.c:6 in the Breakpoint View by clicking on the check box. 6. Click the "Restart" button in the Debug View. 7. Continue execution and notice that execution stops at the disabled breakpoint. Thank You, Ewa Matejska. PalmSouce
Created attachment 33114 [details] Testcase to reproduce the problem.
Works for me. Tried both Linux and Windows.
Hi Mikhail, Previously, I did not notice that while following my own steps in the testcase, I had another session in the "Debug View" in the running state. Sorry about that. I renamed the bug because it seems that the breakpoint problems stem from having another instance of the same debug session already in the running state. I replaced the testcase with another one with a while(1) loop to ensure continued running. Please do the following: 1. Build the testcase. 2. IMPORTANT: Create a debug session with the "Connect process input & output to a terminal" option turned off. Continue running the program. The result should be a debug session in the Debug View in the "running" state. See ScreenshotDebug1.png. 3. Set breakpoint at hello.c:6. 4. Start another debug session of the same kind as in #2 and stop at the first line of main. 5. Disable the breakpoint at hello.c:6. 6. Continue running and notice that the breakpoint is hit even though it's disabled. See ScreenshotDebug2.png. Please let me know if you can see this. Thank You, Ewa.
Created attachment 33285 [details] Screenshot of debug session in running state.
Created attachment 33286 [details] Screenshot of debug session stopped on disabled breakpoint.
Actually, please just modify the original testcase hello.c file to look like: #include <stdio.h> int main() { printf("Hello World!\n"); printf("hello again\n"); while(1); return 0; } I don't want to litter the eclipse bug tracker. Thanks, Ewa.
Ewa, Can you suspend the running session? I believe that one of the reasons to use pty is to be able to break the running application. Unfortunately, with pty we have problems restarting the session.
Hi Mikhail, Yes, I can suspend the running session. I'm not sure I understand your response. I'm only seeing this problem if my debug launches have the "Connect process input & output to a terminal" option turned off. You expected that I would not be able to Suspend because this option was off? Also in the most recent example, I did not have to restart to see the problem but I simply disabled a breakpoint after the execution of the program already started. Do you think this is a limitation of having that option turned off? Thank You, Ewa.
Ok, I'll investigate this on Monday. Thank you for looking at it.
Ewa, I have tried your example, but I can not set a breakpoint after "while(1)", code seems to be optimized even if I use the -O0 option. The error message from gdb is "no line x in file hello.c". If I set a breakpoint somewhere else everything works fine. Mikhail
Hi Mikhail, The problem reproduces for me when I set the breakpoint at the "printf("hello again\n")" line (the second printf statement in the example which is hello:6 for me). Can you verify that you, 1. Turned _off_ the "Connect process input & output to a terminal" option. It doesn't reproduce with that option on. 2. There is one debug session of the same kind in the running state already when you try to see the problem. 3. You set the breakpoint before execution started and you disabled the breakpoint after execution started (disable when stopped at first line of main in the example). If that doesn't work for you, the next step for me will be to look through the source code. Thank You, Ewa.
Yes, I have been able to reproduce it. The suspend command works much faster if the "Connect process input & output to a terminal" option is on, because it uses the terminal specific commands (Ctrl-C, I believe) to suspend a running program. If this option is off, we use different mechanism to suspend a debug session. When you set, delete or modify a breakpoint in UI the corresponding commands are sent to all active gdb sessions. If a session is in the running state, it has to be suspended first. And suspend takes a long time in this case. If you wait for some time after breakpoint is disabled, it would work as expected. I'll check why the delay in one session affects the other. Thanks.
