Crash that occur only in debug mode with a simple project

deleted343

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 !

alt text

In release mode, the app doesn't crash.

Thanks.

JoeCFD

@embeddedmz
Try to use shared pointer in your app

deleted343

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

deleted343

@JoeCFD The crash occured before deleting the pointer. Otherwise, the program is correct.

JoeCFD

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

JonB

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

jsulm

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

KroMignon

@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 sure m_Internals is valid when FoobarManager destructor is called?

deleted343

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

jsulm

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

deleted343

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

Christian Ehrlicher

@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

@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

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

J.Hilk

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

deleted343

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

deleted343

@Christian-Ehrlicher I have already posted the link in the question : https://github.com/embeddedmz/QtCreatorDebugAppCrash

JonB

@embeddedmz
Does it not crash if you do put in Qt::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.

J.Hilk

@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

deleted343

@JonB I still have the same problem.

I'm sure it's Qt Creator using some bad DLLs in debug mode but I don't know how to check that and how to fix it.