Community
Participate
Working Groups
Build Identifier: Eclipse C/C++ Development Tools Version: 7.0.2.201010220608 Build id: 201010220608 We generate C++ code from a model. When the breakpoints are put in the running code, the warning related to Unresolved breakpoints are shown. However, most of the times, after relaunching the application, the warning disappears and breakpoint is installed in the application. Reproducible: Always Steps to Reproduce: 1.Create a CPP project in Eclipse with CDT installed. 2.Create a method with some code in the project int i =0 ; int k = 90; int sum = i + k; printf("%d", sum); Launch the code using C++ debug configuration. Bring up the Code and put a break point at int sum=i+k; The the breakpoint has a warning against it, saying "The breakpoint cannot be resolved"
My version of CDT is 7.0.1, but this happens to me to. You can set breakpoints before you launch the debug session or when the debugger has stopped at some breakpoint, but not when the program is running (under debugger). I propose that you lift the importance of this bug to "major". This really should be fixed right away. I'm voting for this one.
Can you include the 'gdb traces' of your session? http://wiki.eclipse.org/CDT/User/FAQ#I.27ve_been_asked_for_.27gdb_traces.27.2C_where_can_I_find_them.3F
Created attachment 198014 [details] gdb trace - nothing in it even though breakpoint setting was attempted
I can but there's nothing strange about them. I can't see anything in the trace when I'm trying to set the breakpoint while the program is running. There just appears a yellow triangle with exlamation mark on top of the breakpoint "balloon" and then there's this message in the problems window: Description Resource Path Location Type Breakpoint attribute problem: installation failed network.cpp /DRMEditor 451 C/C++ Breakpoint Problem The same note can be seen when hovering the mouse on top of that yellow triangle. I'm attaching the gdb trace anyway. In this trace the program ran into one breakpoint that was set before the debugging session started. But when I tried setting a breakpoint when the program was running, nothing appeared.
(In reply to comment #4) > I'm attaching the gdb trace anyway. In this trace the program ran into one > breakpoint that was set before the debugging session started. But when I tried > setting a breakpoint when the program was running, nothing appeared. Can you indicate at what time you tried to set the breakpoint? Also, can you show the traces when you set a breakpoint with the target stopped (you said that worked). Finally, the very large -environment-directory can affect breakpoints. This has been removed in the next eclipse release, and may help you issue.
Ok. Here's one session: A breakpoint was encountered. Then I set the next breakpoint a few lines further and continued the debugging. The breakpoint which I just set was encountered. Then I continued the debugging and let the program run. Then I tried to set another breakpoint while the program was running, but there was no output in gdb trace. I'm attaching the trace below.
Created attachment 198030 [details] the new trace
(In reply to comment #6) > Ok. Here's one session: A breakpoint was encountered. Then I set the next > breakpoint a few lines further and continued the debugging. The breakpoint > which I just set was encountered. Then I continued the debugging and let the > program run. Then I tried to set another breakpoint while the program was > running, but there was no output in gdb trace. I'm attaching the trace below. And the file where I had those breakpoints was network.cpp. There's a lot of those breakpoints in the trace so it may be confusing. The time when I hit the first breakpoint seems to be 013,257. The time when I set the first breakpoint seems to be 024,944. And I hit that breakpoint at 029,935.
Are there are error in your workspace .metadata/.log around the time you do that debug session?
Well there this one about a missing log file, but I don' think it's related: !SUBENTRY 1 org.eclipse.core.filesystem 4 272 2011-06-15 18:46:42.319 !MESSAGE Could not write file: E:\Users\Marko\Documents\workspace\.metadata\.plugins\org.eclipse.cdt.ui\DRMEditor.build.log. !STACK 0 java.io.FileNotFoundException: E:\Users\Marko\Documents\workspace\.metadata\.plugins\org.eclipse.cdt.ui\DRMEditor.build.log (The system cannot find the path specified) (and then there's the stack trace, which I'm not putting here.) The path to the build log seems to point to the directory where I had the workspace earlier, before I moved it to the current directory.
This bug is still present in CDT 8.0. Is it ever going to be fixed? Maybe it's time to raise the importance level of this bug to major? Here's a really simple test case for whoever will get interested in this (if someone ever will): Make a cpp "helloworld" project and replace the contents of the file with: #include <iostream> using namespace std; int main() { while(1) { cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!! } return 0; } Debug and try to set breakpoint inside the loop WHILE THE PROGRAM IS RUNNING.
Works well on Linux, so I assume this is a Windows problem. There was a lot of effort trying to get windows interrupting to work properly, as it was quite complicated. All the details are in Bug 304096. Which GDB version are you using? Does it work with CDI? To try it, follow the instructions here: http://wiki.eclipse.org/CDT/User/FAQ#How_can_I_choose_another_debugger_integration_for_CDT.3F and choose "Standard Create Process Launcher"
I'm currently facing the same issue as Marko (Eclipse 3.7.0.I20110613-1736 and CDT 8.0.0.201106081058 under Windows XP). > Which GDB version are you using? GNU gdb (GDB) 7.3.50.20110821-cvs (cygwin-special) > Does it work with CDI? To try it, follow the instructions here: > http://wiki.eclipse.org/CDT/User/FAQ#How_can_I_choose_another_debugger_integration_for_CDT.3F > and choose "Standard Create Process Launcher" Doesn't work either here. Actually, there is no trace in the GDB console when trying to set a breakpoint while the program is running.
(In reply to comment #12) > Which GDB version are you using? It's 7.3. > Does it work with CDI? To try it, follow the instructions here: > http://wiki.eclipse.org/CDT/User/FAQ#How_can_I_choose_another_debugger_integration_for_CDT.3F > and choose "Standard Create Process Launcher" No, it doesn't.
(In reply to comment #13) > Actually, there is no trace in the GDB console when trying to set a breakpoint > while the program is running. Can one of you press the Suspend button while the application is running, with DSF and CDI. Does that work? I'm guessing not. Does anyone have a 7.2 or 7.1 GDB? I believe this worked with those versions. I can be downloaded from http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GDB/ BTW, I don't have a Windows machine at the office, so I can't try it myself.
(In reply to comment #15) > Can one of you press the Suspend button while the application is running, with > DSF and CDI. Does that work? I'm guessing not. > > Does anyone have a 7.2 or 7.1 GDB? I believe this worked with those versions. > I can be downloaded from > http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GDB/ I tried that with 7.1, 7.2 and 7.3, all both with DSF and CDI and none of them worked. However I came across a discovery. If you change the code to: #include <iostream> using namespace std; int main() { int i = 0; while(1) { i++; } return 0; } i.e. you don't print anything, then you can set a breakpoint while the program is running. Also in gdb 7.3, with both DSF and CDI. I have a couple of Qt GUI applications and setting a breakpoint in them does not work. They don't print anything to the standard output.
(In reply to comment #16) Out of curiousity, what if you had #include <iostream> using namespace std; int main() { int i =0; while(1) { cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!! i++; } return 0; } Can you interrupt that?
> (In reply to comment #16) > > Out of curiousity, what if you had > > #include <iostream> > using namespace std; > > int main() { > int i =0; > while(1) > { > cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!! > i++; > } > return 0; > } > > Can you interrupt that? No, I can't. But I can interrupt this: #include <iostream> #include <windows.h> #define sleep(n) Sleep(1000 * n) using namespace std; int main() { while(1) { cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!! sleep(5); } return 0; }
Created attachment 203176 [details] Qt test case Trying to set a breakpoint in button handler test_qt::doClicked() doesn't work.
I suggest to try out the test with GDB only, no eclipse: > gdb <path to project>\Debug\hello run ^C This should not work since it seems to be the interrupting ability of GDB that is failing. Until we find a way to get GDB to interrupt in those cases, there is nothing we can do in Eclipse. If you agree, I will mark as NOT_ECLIPSE, but we can re-open if there is a workaround Eclipse could use.
(In reply to comment #20) > I suggest to try out the test with GDB only, no eclipse: > > > gdb <path to project>\Debug\hello > run > ^C It didn't work either. > This should not work since it seems to be the interrupting ability of GDB that > is failing. > > Until we find a way to get GDB to interrupt in those cases, there is nothing we > can do in Eclipse. > > If you agree, I will mark as NOT_ECLIPSE, but we can re-open if there is a > workaround Eclipse could use. Here's a workaround: http://cygwin.com/ml/cygwin/2006-06/msg00321.html The workaround uses DebugBreakProcess function. I compiled the program under the link and was able to interrupt gdb (running under Eclipse). Then I was able to set a breakpoint. I suggest that something similar is done with Eclipse.
Created attachment 203389 [details] Gdb interruptor I made an attachment of the gdb interrupt program presented in the link I supplied earlier for study and testing. The zip contains the source and compiled program. Just try it. Usage: -Start debugging session within Eclipse. -Look up the PID of the program you're debugging from task manager, for example. -Run command "debugbreak.exe [PID]" -The program should stop now somewhere in Eclipse. Now you can set a breakpoint in the code where you want. Then you can continue debugging and the next time the breakpoint you just set is met, the debugger should stop there. The only thing that should be added to the program is the lookup of the PID. There it is, on a golden plate for you. Now only thing left is to someone implement this in Eclipse.
One of our Client is also facing this similar issue . Is it possible to let us know by when this issue can be resolved and implemented in eclipse
