Crash that occur only in debug mode with a simple project
-
@embeddedmz said in Crash that occur only in debug mode with a simple project:
The crash occured before deleting the pointer. Otherwise, the program is correct.
For me, it looks like a "double free" issue.
Are you surem_Internals
is valid whenFoobarManager
destructor is called? -
@KroMignon It's the PIMPL idiom and there's nothing wrong with the code, I used the same style many times on multiple platforms and the issue is not with the code but with the tool. I already put a breakpoint in the destructor and it's not called before the crash !
Like I just said before, with Visual Studio 2019 and vcpkg there's no bugs ! Can you please clone the project and check that it's exiting properly ? Maybe my Qt Creator is mixing DLLs or something like that.
-
@embeddedmz said in Crash that occur only in debug mode with a simple project:
but with the tool
How so? QtCreator is an IDE, nothing more. If there is an issue outside of your code then it is in Qt. But I doubt that. Different behaviour of release and debug builds is usually a sign for a bug in the code. And different compilers can behave differently in such situations.
-
@jsulm No it doesn't have a parent, and I'm competent enough to know these issues. It's an "empty" project, please take a look at it !
Even if I do nothing in the destructor or I remove all delete statements everywhere it still crashes only with Qt Creator in debug mode.
I still believe it's the fault of Qt Creator maybe it's using different DLLs or something like that or a compiling issue.
-
@embeddedmz said in Crash that occur only in debug mode with a simple project:
It's an "empty" project, please take a look at it !
Where? There is no minimal, compilable example somewhere...
-
@embeddedmz What Qt version and compiler do you use?
I just tested on Linux with Qt 5.12.8 and QtCreator 4.11.0 in debug mode and have no crashes. -
@embeddedmz said in Crash that occur only in debug mode with a simple project:
Like I just said before, with Visual Studio 2019 and vcpkg there's no bugs !
Maybe, but are you sure
m_Internals
always have a valid value?
Is it initialized to 0/nullptr when no used?
Be aware with MSVC, MSVC is working differently between release/debug compilation. In debug, MSVC force uninitialized pointer to 0, this may mask some initialization issues! -
@embeddedmz said in Crash that occur only in debug mode with a simple project:
I still believe it's the fault of Qt Creator maybe it's using different DLLs or something like that or a compiling issue.
Nope, works perfectly fine on MacOS ( Qt 5.15.2 & QtC 4.15.0)
-
@jsulm said in Crash that occur only in debug mode with a simple project:
How so? QtCreator is an IDE, nothing more. If there is an issue outside of your code then it is in Qt. But I doubt that. Different behaviour of release and debug builds is usually a sign for a bug in the code. And different compilers can behave differently in such situations.
If your execution environement points to bad shared objects (DLLs in that case) your application can start and crash randomly during run time.
I have to check the PATH folder or something like that but this stuff is usually handled automatically by Qt Creator when debugging. Using a dependency walker cannot help because in the output directory, Qt DLLs are not copied.
-
@Christian-Ehrlicher I have already posted the link in the question : https://github.com/embeddedmz/QtCreatorDebugAppCrash
-
@embeddedmz
Does it not crash if you do put inQt::QueuedConnection
? You are connecting signal and slot while in one thread, so that will be direct connection, then moving one side into a thread. I do not know whether Qt adjusts the connection for you to become queued in this case, you need queued connections between different threads. -
@JonB If its on Qt::AutoConnection (the default, when not specified) then it should "look that up during runtime", IIRC. And adjust accordingly
I would do without the raw
delete
and rather use deleteLater(), some Qt internals do not clean up properly/play nicely when you call the raw delete on QObjects -
@embeddedmz
Looking at your stack trace, what is theQtVisualStudioDebuggerBug
file for which you do not have the source? That name looks a little bit worrying? -
Now, I can't even build after updating VS2019 :
D:\DevProjects\QtVisualStudioDebuggerBug\CMakeLists.txt:3: erreur : No CMAKE_CXX_COMPILER could be found. Tell CMake where to find the compiler by setting either the environment variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH.
Any insights on how to fix this ?
Thanks.
-
I reinstalled Qt, the issue disappeared but now I'm having the commercial version of Qt ??!!?? Fixed this last issue by creating a new Qt account. Please Qt Company, fix your installer.