@JKSH Yes, I created two simple console applications and added required libraries to them. Compiler keys are identical. I checked carefully. A one project have a mistake, and another doesn't have For example, a project with subprojects have this error, but QT Widgets does not have (but not always). Heisenbug?

@jsulm Yep, absolutely, there is much to read/fiddle with, and may not be portable. May or may not work for OP's particular case. Anyway, whether this or your core dump suggestion (OP should look up how his target Linux OS handles core dumps allowed or not), he has a few approaches to consider now....

Hi and welcome to devnet, How are you building your executable ? What version of PyQt5 and Qt are you using ? Since you are using PyQt, you might want to consider contacting its authors.

@JealousFish Yes, In Qt Creator is called “Build Directory”, where file .o are created and where you find your application. In the past I had the same issue, when I deleted the build folder the problem disappeared. Sometimes, when compiler failed and the code seems ok, I delete the builder folder and the problem disappears. I think, but it is only my idea, when this happens some files .o are locked, perhaps because I stopped the previous compile.

@kshegunov @mrjj Thanks for your explanation. Finally I figured out that the problem lay in the signal QGraphicsScene::changed I used. I learned about this signal in an OpenGL example in Qt. By using it I was trying to update my wave soon after its last update, however this signal could also be triggered by changing axis range or window resize, which would probably cause the crash for I didn't consider thread safety and synchronization under this condition. So I defined a custom signal function and now the problem is solved.

OK, seems like shadow casting on the default light might be broken. Turning it on caused the scene to crash.

@JonB Do not misunderstand. I have not said that I will not try your solution. I have just explained my temporary approach that I'm currently using to find the origin of my crashes. For the future I will take time to investigate more with the hope to have a generic solution to apply on all my VS solutions.

By build a debug version do you mean adding -DDEBUG -g to CFLAGS in my makefile? Hooray! Adding the -DDEBUG -g flags to my makefile fixed it! Thank you @aha_1980! I googled for this but nothing really came up, thanks!

@Sergey-I. said in Wrong char type detection in debugger: Has anyone reported this to the bug tracker? I don't know. Did you check that?

@mpergand Yes, this is just what I want. Thanks.

Ok, I've found that the results are stored in files Makefile.Release, Makefile.Debug and everything is explained here.

Thank you for your answer!

Hi and welcome to devnet, I am not aware of such a feature in Qt Creator except what is mentioned here but it doesn't mention keeping the thread being currently view. I'd recommend posting this question on the Qt Creator mailing list. You'll find there Qt Creator's developers/maintaines (this forum is more user oriented)

Did you activate any kind of compiler optimization?

Thank you, Charby! Do you mean Debugger settings/Enable QML? I know about it and suppose it is about Qml application. Am I right? But I ask about “mixed” mode – I can’t understand how to debug qml module which we call from C++ program ( p->runQmlPlugin() )?

Hi and welcome to devnet, In addition to @mrjj, watch out not to deploy your application with Qt Creator's DLLs but the one from the Qt you used to build your application.

Alright. Thanks. That sounded like a lot of work so I scanned through the application's many features and found "Run Settings" has something called "Main QML file" that seems to operate the way I expect.

Dear all, Juste an update on this issue for anyone it could help. The issue came from the INCPATH section of the makefile. Though similar beetween makefile.debug and makefile.release it seems that the compiler (or linker) could not interpret relative path ('../../../') when in release mode (whereas it works ok in debug). I could not find a solution to directly fix this issue so I now modify the makefile once created/updated in order to replace occurences of relative paths by absolute path. This is done using a batch file that I execute after the qmake.exe step (step added in the compilation steps of the project configuration) Thanks to those who tried to help

@Anas-A.-Ismail Try to run some simple qml example and put break point and console.log() in event. Its really strange. I don't think we need some kind of config for console.log().

Hi, What are you exactly trying to start/debug ? It looks like you are building the qttools module.

@TheBadger Thank you that was the right link.

You can try to add your static libraries like this: LIBS += PATH_TO_LIB_DIR/libLIBNAME.lib

I am exactly getting the same problem may be we need to add exception in MSVC

ok after some further research I have found this page (probably the one you @SGaist were referring to) https://forums.developer.apple.com/thread/9233. As you mentioned, it seems that DYLD_* variables have been disabled (they are ignored) since El Capitan because of a new feature called System Integrity Protection (SIP). According to Apple Developer website, debugging can be happily performed only by Xcode (although I haven't tried it yet). What about Qt? Will 5.5.1 or 5.6 allow debugging on El Cap with SIP? I read on another page SIP can be disabled in Recovery mode. Anyway, I am not keen at hacking my own system... the alternative is to wait for the next version of Qt and hope for a solution. Unsure what to do for now, in the meanwhile I am stuck! Grrr UPDATE: I ended up disabling SIP following the following step: Enter Recovery mode (Cmd+R on startup) Open Terminal csrutil disable; reboot Now debugging went back to normality! My only doubt is that when i do csrutil status, I receive the following message: "System Integrity Protection status: enabled (Custom Configuration). Configuration: Apple Internal: disabled Kext Signing: disabled Filesystem Protections: disabled Debugging Restrictions: disabled DTrace Restrictions: disabled NVRAM Protections: disabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state." Not very reassuring uh? (and why is that still saying SIP enabled?)

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.

Hi, Do you have gdbserver installed on your device ?