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 but then you find the actual reason    for all your problems and then you feel like :)

@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!

@Mark81 said: SIGILL That is an illegal instruction signal, which is pretty rare. Basically means the memory your program's residing in got corrupted somehow. So there's something very wrong. Check any callbacks, overwriting by mistake virtual tables and the such.

Switch of "Run in Terminal" in your project's Run settings, and check whether this makes a difference.

Did you activate qml debug checkbox in your project settings (runtime tab of your kit settings)?

Then, double check to ensure you did also install the debugger. It's not part of the Visual Studio installation. [edit: added missing part]

@TheBadger Thank you that was the right link.

I'm not sure which cache folder are you talking about. Anyway, you should use the one that was in the same folder as your exe.

Qt i debugger to 2 różne rzeczy. Nie zaśmiecaj PATH. Dodawanie tam Qt nic nie da a może sporo popsuć. Którego IDE używasz - Qt Creator czy Visual Studio? Jesli Qt Creator to który kompilator - MinGW czy kompilator z Visual Studio? Jeśli MinGW to gdb (debugger) powinien być zainstalowany razem z nim i ustawiony automatycznie. Żeby zainstalowac debugger dla VS trzeba zaznaczyc opcję "Debugging tools for Windows" instalując Windows SDK. Napisałeś że zainstalowałeś całe, ale upewnij się - sprawdź, czy w ścieżce <ścieżka do Windows SDK>/Debuggers/x64/ jest plik cdb.exe (plik debuggera). Jesli nie to pewnie ominąłeś ten checkbox w instalatorze. Sprawdź, czy Qt Creator widzi debugger - Tools -> Options -> Build & Run -> Debuggers: powinieneś tam widzieć coś w rodzaju "Auto-detected CDB at ...". Sprawdź, czy twój kit ma ustawiony debugger (pewnie nie jesli doinstalowałeś go potem. Wejdź do Tools -> options -> Build & Run -> Kits, zaznac swój kit i zobacz czy ma usatwiony debugger. Jesli nie to wybierz CDB z listy.

@kuzulis I downloaded the versions of gdb and python as mentioned in the script you mentioned . now my project is working fine. I used this link to install gdb .

added them in rebult and ran qmake, then attempted it again. Breakpoints are still being ignored.

Hi, You are probably missing the path to your GStreamer dlls in your PATH (the one in Qt Creator not for your system) You can modify it in the Run part of the Projects Panel

Thanks for the reply. I have read the link about the pipe and tried a couple of other things (they didnt' work anyway ) First, i renamed the external pipe in VmWare settings to : superpipe22. I made sure, that the pipe is connected to vmware. Also the name of the computer in VmWare operating system (windows 8) is : SUPERPC Then i changed the server creation first like this: ** cdb -server npipe:pipe=\S UPERPC\pipe\superpipe22 C:\tests\clean_deploy\clean_deploy\myapp.exe** and tried to connect with npipe:server=SUPERPC,pipe=\SUPERPC\pipe\superpipe22 npipe:pipe=\SUPERPC\pipe\superpipe22 npipe:server=SUPERPC,pipe=superpipe22 npipe:server=SUPERPC,pipe=superpipe22 Then i went to cdb folder, manually ran it and tried: 1 cdb -QR \\SUPERPC Servers on \\SUPERPC: Unable to query \\SUPERPC 2 cdb -QR \\SUPERPC\pipe\superpipe22 Servers on \\SUPERPC\pipe\superpipe22: Unable to query \\SUPERPC\pipe\superpipe22 3 cdb -QR \\.\pipe\superpipe22 Servers on \\.\pipe\superpipe22: Unable to query \\.\pipe\superpipe22 So cdb cannot access the VmWare even trough the pipe. I think the problem is that VmWare is not reachable under the name SUPERPC. I know its not the topic of this forum, but can you suggest any tips, on how i can access my VmWare OS by the servername? My VmWare is not using bridged connection it has its own network with its own modem etc. (That's why i'm testing my application there).

Well, if you've been using it already for so long and you didn't find it frustrating then it's okay, my comment was only for newbies (and you're no longer in that category after months of using it)