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

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

Finally I solved this by android API/SDK upgrade (17 -> 19).

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

So nobody ever profiled Qt application for Android? Is there a solution?