Community
Participate
Working Groups
Build Identifier: CDT 7.0.0.201005311212 Consider the following code snippet that uses a class from the Qt library: QFileInfo FileInfo( "/tmp/test.txt" ); char * name = FileInfo.filePath().toLatin1().data(); Set a breakpoint on the second line and step into the method (F5) when the breakpoint is hit. Immediately after entering the method filepath() the debugger stops and I am unable to continue debugging. Resume is impossible. I have to kill the debug session. In the Variables View I can see: Name : this Details:0x0 Default:<value optimized out> Reproducible: Always
Created attachment 171337 [details] gdb traces
Created attachment 171338 [details] source code for testing
Created attachment 171340 [details] Qt .pro file to generate Makefile To get the test code working you need: 1) Qt4 installation (I am not sure if debug symbols are sufficient; I have downloaded the whole Qt source code and compiled the library myself; the crash happens within the Qt source code) 2) Generate a Makefile: qmake dsf-test.pro 3) Set a breakpoint on line 6 4) step into the method (F5) when the breakpoint is hit 5) the rest should be obvious :) There is no problem when I step through the code using CDI instead of DSF. The variable "this" in the method QFileInfo::filePath() has then a valid address!
(In reply to comment #0) > In the Variables View I can see: > Name : this > Details:0x0 > Default:<value optimized out> Just to be clear. The Qt library was compiled with optimization turned on. So the critical code might be actually optimize out. However, from comment #3 one can see that the CDI (and gdb from the command line) have no problem with it.
I won't be able to look at it this week. However, I think having the CDI gdb traces would be useful. Would it be possible to attach them also?
Created attachment 171386 [details] gdb traces for CDI
I was able to create a much simpler test case without Qt. The infamous HelloWorld.c #include <iostream> #include <cstdio> using namespace std;int main() { printf("Hello world\n"); return 0; } int main() { printf("Hello world\n"); return 0; } Compile it using the release configuration with optimization turned on. Single step through the application (F5: Step into). If you are using DSF it will stop immediately at printf. Debug version w/o optimization works flawlessly. I changed the title of this bug to reflect this.
I'm reducing the importance since this is related to optimized code. I'm not really sure what we should support for debugging optimized code. At the least, we should be as good as CDI.
(In reply to comment #7) > I was able to create a much simpler test case without Qt. The infamous > HelloWorld.c > > #include <iostream> > #include <cstdio> > using namespace std; > > int main() { > printf("Hello world\n"); > return 0; > } > > Compile it using the release configuration with optimization turned on. Single > step through the application (F5: Step into). If you are using DSF it will stop > immediately at printf. Debug version w/o optimization works flawlessly. > I changed the title of this bug to reflect this. I created a new HelloWorld project using the Wizard and replaced the code with what is shown above. I select the project properties so that the compiler uses -O3. I then Debug As->Local app but single stepping works fine. Do you do something different? I'm on Linux 32bit.
(In reply to comment #8) > I'm reducing the importance since this is related to optimized code. I'm not > really sure what we should support for debugging optimized code. > > At the least, we should be as good as CDI. I am fine with reducing the importance. Usually I do not debug optimized code. But sometimes it is necessary when a bug only occurs in the release code or debug code is to slow etc. I stumbled across this specific bug while debugging my own non-optimized code. I was stepping into some function of the Qt lib - which is optimized - when the freeze happened. A less uncommon scenario.
(In reply to comment #9) > (In reply to comment #7) > > I was able to create a much simpler test case without Qt. The infamous > > HelloWorld.c > > > > #include <iostream> > > #include <cstdio> > > using namespace std; > > > > int main() { > > printf("Hello world\n"); > > return 0; > > } > > > > Compile it using the release configuration with optimization turned on. Single > > step through the application (F5: Step into). If you are using DSF it will stop > > immediately at printf. Debug version w/o optimization works flawlessly. > > I changed the title of this bug to reflect this. > > I created a new HelloWorld project using the Wizard and replaced the code with > what is shown above. I select the project properties so that the compiler uses > -O3. > > I then Debug As->Local app but single stepping works fine. > > Do you do something different? > > I'm on Linux 32bit. 1) Create a Hello world project with the project wizard 2) substitute the code with my example code from above 3) change to the Release Build Configuration and build the project 4) Create a debug launch configuration for the Release binary (be sure not to debug the debug version!) I'm on Linux 64bit.
(In reply to comment #11) > 1) Create a Hello world project with the project wizard I created a C++ one > 2) substitute the code with my example code from above > 3) change to the Release Build Configuration and build the project > 4) Create a debug launch configuration for the Release binary (be sure not to > debug the debug version!) When debugging the release version, I can't even properly stop on main(). Probably because the release version is not build with -g. How come it works for you? When I debug the Debug version built with -O3, I don't see the problem. > I'm on Linux 64bit. I tried with CDT 6 and it still worked as I saw with 32 bits. I'd have to setup CDT 7.0 on my 64bit machine to test it properly, but I wanted to get more info about the above before doing that. Thanks
(In reply to comment #12) > (In reply to comment #11) > > 1) Create a Hello world project with the project wizard > > I created a C++ one I did the same. > When debugging the release version, I can't even properly stop on main(). > Probably because the release version is not build with -g. Sorry, I forgot to mention this. You have to add -g to the compiler options. The debugger will stop then in stdio2.h: printf (__const char *__restrict __fmt, ...) { return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); > > When I debug the Debug version built with -O3, I don't see the problem. I can reproduce the problem with the Debug build when I set -O3 > > I'm on Linux 64bit. > > I tried with CDT 6 and it still worked as I saw with 32 bits. Same problem with 32bit (cross-compiled on my 64bit machine with compiler/linker option -m32).
Marc, were you able to reproduce the problem?
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > 1) Create a Hello world project with the project wizard > > > > I created a C++ one > I did the same. > > > When debugging the release version, I can't even properly stop on main(). > > Probably because the release version is not build with -g. > Sorry, I forgot to mention this. You have to add -g to the compiler options. > The debugger will stop then in stdio2.h: > printf (__const char *__restrict __fmt, ...) > { > return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); My stopped on the printf. > > > > When I debug the Debug version built with -O3, I don't see the problem. > I can reproduce the problem with the Debug build when I set -O3 > > > > I'm on Linux 64bit. > > > > I tried with CDT 6 and it still worked as I saw with 32 bits. > Same problem with 32bit (cross-compiled on my 64bit machine with > compiler/linker option -m32). Here is what I do: 1-start eclipse 3.6 with CDT 7.0 installed. 2-use a brand new workspace 3-in the C/C++ perspective, right-click on project explorer view and select new->C++ project 4- choose type Executable->Hello world, name project and touch nothing else. press finish 5-replace content of source file with the simple example you gave. Save. 6- right-click on project and select Build configurations->manage... 7-click on Release and press Set Active then press OK 8-right-click on project and select properties, c/c++build->settings 9-in the tab Tool Settings, in the first set called "GCC C++ Compiler" click on Debugging and choose Debug level "default (-g)". Press OK 10- click on editor then choose menu Project->Build project 11- Choose menu Run->Debug configurations... 12-double-click on C/C+ Application 13- in the main tab, click on Search project and choose the release version 14- in the debugger tab make sure to use GDB 7.0 15- change nothing else and press Debug 16- it automatically changes to the debug perspective and the code is stopped on the printf line. 17- press F5 and it goes to the last bracket properly.
(In reply to comment #15) > Here is what I do: > 1-start eclipse 3.6 with CDT 7.0 installed. > ..... Your instructions match in principle what I have done. But to be sure I followed your instructions exactly. And the debugger still hangs as mentioned in comment #13 in stdio2.h: printf (__const char *__restrict __fmt, ...) { return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); The difference might be that I use gdb 7.1 (not 7.0). Which gcc version do you use? Mine is 4.4.3 (Ubuntu 10.04). This affects how the code is optimized.
(In reply to comment #16) > (In reply to comment #15) > > Here is what I do: > > 1-start eclipse 3.6 with CDT 7.0 installed. > > ..... > Your instructions match in principle what I have done. But to be sure I > followed your instructions exactly. And the debugger still hangs as mentioned > in comment #13 in stdio2.h: > printf (__const char *__restrict __fmt, ...) > { > return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); > > The difference might be that I use gdb 7.1 (not 7.0). Which gcc version do you > use? Mine is 4.4.3 (Ubuntu 10.04). This affects how the code is optimized. Still works for me with GDB 7.1. But my gcc is, brace for it, 4.1.2. Can you attach the binary in question to this bug and I'll try it directly. Thanks
Created attachment 175013 [details] Helloworld binary (32bit) Helloworld binary (32bit) compiled with gcc 4.4.3 (on Ubuntu 64Bit).
(In reply to comment #18) > Created an attachment (id=175013) [details] > Helloworld binary (32bit) > > Helloworld binary (32bit) compiled with gcc 4.4.3 (on Ubuntu 64Bit). Sorry for the delay. I will need the source code because the attached binary does not match the example I was using and gdb is complaining: Line number 14 out of range; ../src/HelloWorld.cpp has 8 lines.
Created attachment 176084 [details] HelloWorld sourcecode
Created attachment 176712 [details] test fix Ok, I see it. Let's just make sure we see the same thing. In my case, I end up at stdio2.h:105. The session is not actually frozen, but no runControl actions are enabled, so we cannot resume or step, which make it look like things are frozen. If you go to the gdb console and type next, it fixed things for me. The problem seems to be that GDB does not issue a *running even when we do our -exec-step in this case. Looks like a GDB bug. -exec-next (step over) does give a *running event. Without the *running event, DSF-GDB does not realize that the step has been done, so it does not allow new steps/resume. Here is a very simple fix to confirm that we are talking about the same issue. I'm not sure this will be the final fix just yet. Axel, can you try it and see if it fixes the problem you actually see.
I noticed a difference with CDI: although GDB reports stopping in stdio2.h:105 when doing the step-in, CDI still shows as if we were stopped on the printf line. DSF-GDB actually goes into the printf. I wonder if DSF-GDB should do that or not?
(In reply to comment #21) > Created an attachment (id=176712) [details] > test fix > > Ok, I see it. Let's just make sure we see the same thing. In my case, I end > up at stdio2.h:105. The session is not actually frozen, but no runControl > actions are enabled, so we cannot resume or step, which make it look like > things are frozen. > > If you go to the gdb console and type next, it fixed things for me. > > The problem seems to be that GDB does not issue a *running even when we do our > -exec-step in this case. Looks like a GDB bug. -exec-next (step over) does > give a *running event. > > Without the *running event, DSF-GDB does not realize that the step has been > done, so it does not allow new steps/resume. > > Here is a very simple fix to confirm that we are talking about the same issue. > I'm not sure this will be the final fix just yet. > > Axel, can you try it and see if it fixes the problem you actually see. Cool. That fix helps.
(In reply to comment #22) > I noticed a difference with CDI: although GDB reports stopping in stdio2.h:105 > when doing the step-in, CDI still shows as if we were stopped on the printf > line. DSF-GDB actually goes into the printf. > > I wonder if DSF-GDB should do that or not? I prefer the way DSF-GDB does. It seems more logically.
(In reply to comment #21) > Here is a very simple fix to confirm that we are talking about the same issue. > I'm not sure this will be the final fix just yet. Any news on this?
(In reply to comment #25) > (In reply to comment #21) > > Here is a very simple fix to confirm that we are talking about the same issue. > > I'm not sure this will be the final fix just yet. > Any news on this? I went through the different code that was relevant (the different RunControl services versions that we have) and the proposed fix looks safe. In fact, GDBRunControl_7_0_NS already had that logic. I'm just going to run the JUnit tests to make sure (I need to do this from work tomorrow)
Committed to HEAD and 7_0 Pawel, can you review?
Axel, thanks for your help.
*** cdt cvs genie on behalf of mkhouzam *** Bug 316060: DSF-gdb freezes application while stepping through optimized code [*] MIRunControl.java 1.28 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIRunControl.java?root=Tools_Project&r1=1.27&r2=1.28 [*] MIRunControl.java 1.27.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIRunControl.java?root=Tools_Project&r1=1.27&r2=1.27.2.1
(In reply to comment #28) > Axel, thanks for your help. You're welcome and thanks for the patch.
