@MHuysmans I think it is intended behaviour. But whatever it should have nothing to do with Qt Creator. That is only a front-end to whatever debugger you use. Which you don't say. So go test this behaviour in the debugger, e.g. gdb with step and next commands.

@Ronhald OK, I've been digging around in this. Unfortunately, the debug helpers seem to focused on providing a more human-friendly depiction of complex structures. For basic integers the displayed data is actually formatted by Qt Creator's C++ code using QString::number(). This suppresses leading zeros. It may be possible to customise the Qt Creator source to take into consideration the sizeof(IntType) to generate a string of appropriate length.

to continue the point @Christian-Ehrlicher mentioned above, blocking serial tasks usually exist on server daemon applications, but not on anything with user interaction or a GUI.

@williamsk Ah, cool. So as your problem is solved, please mark this topic as SOLVED too (button Topic Tools). Thanks and regards

@Gustaf-D As far as I know there's no such thing for Qt Creator, but if your app can run on Windows you can use Visual Studio to attach a debugger and use the Diagnostic Tools. They have function call graphs, CPU and memory profiling, hot path discovery and much much more. You can start/stop data collection on breakpoints like you asked.

Hm, it should work then, no idea.

@fcarney I can't beleive I missed your question. Comparing with Heob, Deleaker provides more features like taking snapshot at any moment, and comparing them later. Besides heap allocations, Deleaker also tracks COM/ActiveX/GDI/USER32 leaks etc.

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

@skylendar you shortened the log, so I can't see the GDB version. Please check these. Also, GDB must be python enabled, and last the python dumper script must be loaded. Have you checked the directories? Regards

Hi, Why are you mixing both like that ?

Thanks @koahnig and @aha_1980. I will setup a smaller Project an then do the recommended steps. Regards...

@jsulm there was in fact a problem with window3d() that MinGW didnt complain about! Thanks! @JonB no I had commented out only up to the second screenshot, so that's why this was the problem. And about the second issue, to be honest I adapted the constructor from an older version of the application and it also had &argc. At one point I also noticed it and now I tried out both and both work.

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!

how about changing to MinGW 64 ?

Thanks for this Adam. It seems that disabling Load .gdbinit does the trick. Do you know why this is a problem?

What does you code do ?