@SGaist Great!! Thanks!!

I may have found the key condition for this: inconsistent capitalization between the file on disk and the entry in your project file. My project is all CMake, and CMakeLists.txt specified a capital letter in the parent directory of the source file; but it was in lower case on disk.

Bug report here: https://bugreports.qt.io/browse/QTCREATORBUG-27123
Related: https://bugreports.qt.io/browse/QTCREATORBUG-18007

@RyanEdward Although not a native QTCreator solution, I use: C gist to simulate key presses on linux.
Mapping this binary to a keyboard shortcut on your native desktop environment can hack your way to a solution.

For those experiencing the same problem as myself, check your path for perivous GNU mingw installation.
I personally am a GNU user, so i have 64-bit mingw installed on my desktop, that's causes a confliction with the one come with QT creator installation.

@SGaist
Indeed he is
   but if you feed him bugs
after midnight then he goes like

alt text

but then you find the actual reason
   for all your problems and then you
feel like

alt text

:)

@dave2
for completeness sake, I tested it with MacOS & Clang + LLDB, doesn't work at all there as well

This could be temporary issue. Change the configuration from debug to release. Qt Creator will try to reconfigure your project again. Now change back to debug. It will reconfigure again.

@jsulm It seems to be fixed, but I am not sure what did it. I performed a complete sweep for viruses an malware, nothing major found. Then switched to Win10 (I go back and forth between win8 and win10), and for a while my app would not even start, with a error 0xc0000139. Did a search for that error on the web, not much help. Used depends.exe to see what DLLs were getting loaded, but found out that is a dead project, not applicable to win10. Updated a third party app I link into. Then win10 decided to do an update, which fixed the 0xc0000139 error. I cleaned up some logging events, and that improved the slow startup issue, but I cant believe that was the entire fix. Given I did so much in no certain order, in the end I cant identify what did the trick!

@Rguessford I would also be interested to get the Qt Creator Debug button to work for both, Python and QML debugging, at the same time. Even with QQmlDebuggingEnabler instantiated.
I think, I'm stuck at the same as @Jeff-B-0

It does it inside some functions for the this but in any function for the value of a QSharedPointer.

So I guess the problem with this isn't really a problem, but for the QSharedPointer, it wasn't like this before... I've always been able to open it and see the pointer (or NULL if it is not instanciated)

gcc:

gcc version 6.4.0 20170820 (Debian 6.4.0-4)

gdb:

GNU gdb 7.11.1

Program code:

#include <iostream> using namespace std; int main() { cout << "Hello World!" << endl; return 0; }

@Wael11
For anyone reading this: This is known behaviour, which I stumbled across a long time ago and it was infuriating.

With a QSpinbox Qt Internal code uses a timer on clicks/presses. If you step through in debugger you exceed the timeout and get bad/double behaviour.

Simplest: change all connect() to QSpinbox click/key to pass Qt::QueuedConnection as last parameter for connection type, not default Qt::DirectConnection. Now you can use debugger breakpoints and all will be well. I wrote a method to connect all my spinboxes like this.

Any ideas?

The same question had been brought up at the Qt mailing list years ago:
http://lists.qt-project.org/pipermail/interest/2015-September/018826.html

But the things suggested there did not helped me.
Adding an expression for the d pointers did not help either.

@Technologist
Which python and mingw version do you use?

@mrjj , Thanks bud. It worked. You have just made my life easier.

Worked! Thank you very much!