Creator: Setting Breakpoints stops debugger from showing local variable contents
Hello, I'm wondering if the issues I have are just a matter of wrong settings somewhere or if they can be fixed some other way. I'm on Windows 7 (x64) using QtCreator 3.0 with Qt 5.2 and the bundled MinGW 4.8.
I have created a trivial test project (barely more than what the 'new project'-wizard generates) to make sure this isn't caused by something in my main project, and all problems persist in this trivial project.
My main problem:
When I debug the project, everything works just fine just as long as a breakpoint is set at the time I press "F5" to start debugging, and it is 'hit' before I change any breakpoints. After it has been hit I can add/remove/modify breakpoints at my leisure without any issues.
If I do not have one set on launch or if it isn't hit, things start breaking the instant I do set (or unset) one:
The program is immediately halted (as if a breakpoint was hit) in "Thread: #7" (or rarely #8) in function ntdll!LdrFindResource_U of C:\Windows\system32\ntdll.dll (being called from ntdll!RtlQueryTimeZoneInformation).
The debugger complainins "Disassembler failed: Cannot access memory at address 0x7708fff9" (as far as I can tell that address is constant).
I can continue normally (F5) from here, all changes to the breakpoints are applied correctly and all breakpoints do work, but:
If any breakpoint is now hit, the "Locals and Expressions" window remains empty and no variable content is displayed. It doesn't matter if the breakpoint was present before adding/changing/removing one or not, from now on I can't see any variable contents.
Once again, none of this happens if a breakpoint is hit that was set before the debugging was started. After that I can modify all as much as I want, the local variables are correctly displayed and everything works as it should.
I can of course post a debugger log if that would help but didn't want to clutter the post with a wall of text like that unless it was actually needed.
Another problem (much smaller, but possibly related): About 70% of the time when I press the red stop button to stop the debugger, I get an error-message-box: "Failed to shut down application! Application process could not be stopped: The program is not being run". This is clearly nonsense as the program was running and stopped just fine. The debugger log shows that "kill" is executed twice, the first time it stops the program just fine, the second time it generates the error.
in my opinion not being able to set breakpoints while the program is actually running shouldn't be such a big deal (just set/change the breakpoints when the program is halted, i think this should be pretty much sufficient for just about all the debugging needs)
however, the "another problem (much smaller)" with two halts instead of one when you press "stop" just once is actually pretty serious and much more likely to be accepted by the developers as a true bug.
I'd say you should file a bug report for the second, with the exact steps to reproduce
Yes, once you know how to work around the problem it's merely inconvenient. Finding out how to do that in the first place took many hours though, and it was not a fun time by any means...
I'll probably report both as a bug since I don't seem to be getting any replies here. I can only presume that means it's not a common problem (which is what I wanted to make sure it isn't before reporting anything), and the solution isn't readily known in the community.
FWIW, the second problem (two halts instead of one) has apparently been fixed in the nightly builds (i also ran into this but it didn't strike me as serious until read your report, and with the latest nightly of creator it's [from what i can see] not happening any more)
in case you don't know, nightly builds are here: http://download.qt-project.org/snapshots/
Maybe I'm missing something, but the originally described problem strikes me as showstopper serious. I mean, as far as I could tell until finding this thread, the display of local variables is completely broken in QtCreator. I see a blank window and nothing else each and every time I hit a breakpoint. I am happy to now know there is a workaround, but it's insane to think people will figure this out on their own or not notice the problem. How can you not notice a completely blank display of local variables? It makes the debugger practically useless for most uses unless one just so happens to have already set a breakpoint and hit it before adding new breakpoints.
You're quite right. As I mentioned originally, it took me quite some time to pin why it worked only sometimes. And yes I completely agree that this is a serious problem/bug. Why gyll (who replied first) doesn't think so is beyond me. The debugger is the most essential tool for development after the UI/Editor in my opinion. So needing a workaround just to set breakpoints while it's running is a problem.
I'm very thankful for your response, since I wasn't sure if this was just my problem (or just this machine) or if it was a general or - at the very least - somewhat common issue. I'll report this as a bug to the official bug tracker in the next few days then.
I should have mentioned also that I'm extremely grateful you found a workaround and reported the problem. It's extremely unlikely I would have discovered this on my own, and I would have probably had to revert to 5.1. I'm considering doing this anyhow, because this workaround is really unacceptable - after all, you have to remember to go through those extra handstands before you start debugging or else it's too late.
Ok I'm glad to report that the just released QtCreator 3.0.1 fixes this issue.
From the "changelog":https://qt.gitorious.org/qt-creator/qt-creator/source/ff38bb51430d48d5e201ad792cde62b02e273554:dist/changes-3.0.1, it seems to be this:
- GDB: Fixed inserting breakpoints while application is running (QTCREATORBUG-11084)
Glad this is fixed, was a real pain to work around, even though the workaround wasn't that complicated...
Actually it has been fixed a few weeks ago already, it was working fine in the nightly builds that i recommended (that's why i didn't come back with a new comment to this post). Glad it's fixed though, apparently it was a regression
[quote author="gyll" date="1391696460"]Actually it has been fixed a few weeks ago already, it was working fine in the nightly builds that i recommended (that's why i didn't come back with a new comment to this post). Glad it's fixed though, apparently it was a regression[/quote]
Yea I saw your post of course, but I didn't have the time to switch to the nightlies for a fix, and I especially couldn't afford any instabilities (which are always a possibility with nightlies). I'm just glad the fix has reached the stable branch and everything is back to working as it should :)