@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!
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() )?
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.
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)
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)
csrutil disable; reboot
Now debugging went back to normality!
My only doubt is that when i do csrutil status, I receive the following message:
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.
@koahnig actually the project is using lots of locally compiled libs so a "quick" recompiling is not a possible solution to try out (qt uses different compiler with version newer than v5.2).
However, once getting back to my problem I tested some debug config checkboxes and it turned out that the debug helpers were the "problem". Turning off showing thread names did not cause the debugger to stop deep in qt code several times anymore.
In the end it is a pity not understanding what is going on when ticking that config option, though I am glad getting back to debugging now!