Crash that occur only in debug mode with a simple project
-
Hello,
I, initially, created this simple project (CMake is used instead of qmake) : https://github.com/embeddedmz/QtCreatorDebugAppCrash to report a problem that I had with Visual Studio 2019 debugger (and using the Qt binaries provided by vcpkg) and that disappeared in my original application : the debugger freezes when it hits a breakpoint in a lambda and the pause button is grayed out in VS2019. Strangely, adding "Qt::QueuedConnection" fixed the problem (the CanBusManager object is living in another thread, auto connection is sufficient and used the same style as the github project which link is posted above):
QObject::connect(cbm, &CanBusManager::boardErrorsReceived, this, [this](ErrorItem err) { m_Internals->ph66ErrorsModel->setData(err); }, Qt::QueuedConnection);Today, I tested and I don't need to add "Qt::QueuedConnection" anymore. Maybe a VS2019 update fixed something in the debugger.
Instead, I want to report this issue related to Qt Creator (with which I created the example project) : in debug mode when closing the window, there's a crash in a destructor. I analyzed the code of https://github.com/embeddedmz/QtCreatorDebugAppCrash and there's no stuff that can cause undefined behavior in this simple project !
In release mode, the app doesn't crash.
Thanks.
-
Hello,
I, initially, created this simple project (CMake is used instead of qmake) : https://github.com/embeddedmz/QtCreatorDebugAppCrash to report a problem that I had with Visual Studio 2019 debugger (and using the Qt binaries provided by vcpkg) and that disappeared in my original application : the debugger freezes when it hits a breakpoint in a lambda and the pause button is grayed out in VS2019. Strangely, adding "Qt::QueuedConnection" fixed the problem (the CanBusManager object is living in another thread, auto connection is sufficient and used the same style as the github project which link is posted above):
QObject::connect(cbm, &CanBusManager::boardErrorsReceived, this, [this](ErrorItem err) { m_Internals->ph66ErrorsModel->setData(err); }, Qt::QueuedConnection);Today, I tested and I don't need to add "Qt::QueuedConnection" anymore. Maybe a VS2019 update fixed something in the debugger.
Instead, I want to report this issue related to Qt Creator (with which I created the example project) : in debug mode when closing the window, there's a crash in a destructor. I analyzed the code of https://github.com/embeddedmz/QtCreatorDebugAppCrash and there's no stuff that can cause undefined behavior in this simple project !
In release mode, the app doesn't crash.
Thanks.
-
I forgot to say that I generated with CMake a Visual Studio solution and it doesn't crash at exit and in debug mode ! It uses Qt binaries managed by vcpkg.
Qt Creator 4.13.2 based on Qt 5.15.1 (MSVC 2019, 64 bit) From revision 2ee1af2032
-
@JoeCFD The crash occured before deleting the pointer. Otherwise, the program is correct.
-
@JoeCFD The crash occured before deleting the pointer. Otherwise, the program is correct.
@embeddedmz that means the pointer of FoobarManager might be deleted twice.
in your destructor code, it may be a good practice to do the following for all raw pointers:
if ( nullptr != m_Internals ) {
delete m_Internals;
m_Internals = nullptr;
}
if shared pointer is used, it is not needed. Therefore, shared or unique pointers are strongly recommended. -
Hello,
I, initially, created this simple project (CMake is used instead of qmake) : https://github.com/embeddedmz/QtCreatorDebugAppCrash to report a problem that I had with Visual Studio 2019 debugger (and using the Qt binaries provided by vcpkg) and that disappeared in my original application : the debugger freezes when it hits a breakpoint in a lambda and the pause button is grayed out in VS2019. Strangely, adding "Qt::QueuedConnection" fixed the problem (the CanBusManager object is living in another thread, auto connection is sufficient and used the same style as the github project which link is posted above):
QObject::connect(cbm, &CanBusManager::boardErrorsReceived, this, [this](ErrorItem err) { m_Internals->ph66ErrorsModel->setData(err); }, Qt::QueuedConnection);Today, I tested and I don't need to add "Qt::QueuedConnection" anymore. Maybe a VS2019 update fixed something in the debugger.
Instead, I want to report this issue related to Qt Creator (with which I created the example project) : in debug mode when closing the window, there's a crash in a destructor. I analyzed the code of https://github.com/embeddedmz/QtCreatorDebugAppCrash and there's no stuff that can cause undefined behavior in this simple project !
In release mode, the app doesn't crash.
Thanks.
@embeddedmz said in Crash that occur only in debug mode with a simple project:
Instead, I want to report this issue related to Qt Creator (with which I created the example project)
Your code has some kind of error in it. At least that is the most likely presumption. This is not an issue about Qt Creator. Yes, it is quite normal for bugs to only show up in Release or Debug.
Maybe someone will look through your code to try to find the issue. But if there is a real problem can't you reduce your code a lot to reproduce?
-
Hello,
I, initially, created this simple project (CMake is used instead of qmake) : https://github.com/embeddedmz/QtCreatorDebugAppCrash to report a problem that I had with Visual Studio 2019 debugger (and using the Qt binaries provided by vcpkg) and that disappeared in my original application : the debugger freezes when it hits a breakpoint in a lambda and the pause button is grayed out in VS2019. Strangely, adding "Qt::QueuedConnection" fixed the problem (the CanBusManager object is living in another thread, auto connection is sufficient and used the same style as the github project which link is posted above):
QObject::connect(cbm, &CanBusManager::boardErrorsReceived, this, [this](ErrorItem err) { m_Internals->ph66ErrorsModel->setData(err); }, Qt::QueuedConnection);Today, I tested and I don't need to add "Qt::QueuedConnection" anymore. Maybe a VS2019 update fixed something in the debugger.
Instead, I want to report this issue related to Qt Creator (with which I created the example project) : in debug mode when closing the window, there's a crash in a destructor. I analyzed the code of https://github.com/embeddedmz/QtCreatorDebugAppCrash and there's no stuff that can cause undefined behavior in this simple project !
In release mode, the app doesn't crash.
Thanks.
@embeddedmz Does FoobarManager have a parent? You could have a double delete.
And this issue has absolutely nothing to do with QtCreator which is an IDE. -
@JoeCFD The crash occured before deleting the pointer. Otherwise, the program is correct.
@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_Internalsis valid whenFoobarManagerdestructor is called? -
@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_Internalsis valid whenFoobarManagerdestructor 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.
-
@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.
-
@embeddedmz Does FoobarManager have a parent? You could have a double delete.
And this issue has absolutely nothing to do with QtCreator which is an IDE.@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...
-
@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 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. -
@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:
Like I just said before, with Visual Studio 2019 and vcpkg there's no bugs !
Maybe, but are you sure
m_Internalsalways 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! -
@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:
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)
-
@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 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.
-
@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...
@Christian-Ehrlicher I have already posted the link in the question : https://github.com/embeddedmz/QtCreatorDebugAppCrash
-
@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. -
@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
deleteand rather use deleteLater(), some Qt internals do not clean up properly/play nicely when you call the raw delete on QObjects -
@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.
