My Qt 6.6.0 code crashs in debug mode (~QArrayDataPointer()) and not on release on Windows

Nelson numerical software

one thread for gui
one thread for algo.

Same code with qt6.5 in debug mode (with qt release mode) on windows does not crash.

I will try with debug version of qt6.6 if I have same behavior.

jsulm

@Nelson-numerical-software said in My Qt 6.6.0 code crashs in debug mode (~QArrayDataPointer()) and not on release on Windows:

one thread for gui
one thread for algo.

So, do you manipulate UI from the algo thread or not? This is not supported and can lead to crashes.
And please post code as text not pictures.

Nelson numerical software

@jsulm

current examples with crash are simple call to gui feature.
I do not manipulate ui from algo.
In release mode, it works with qt6.6.0 but not in debug
same code also works in Qt6.5.0 in debug mode.

00007ffa467acb2c()
00007ffa467b0275()
00007ffa467b0988()
QArrayDataPointer<QString>::~QArrayDataPointer<QString>()
[Code externe]
Nelson::HelpCollection::getRegisteredFiles()
Nelson::HelpBrowser::getAttributes()
Nelson::HelpBrowserGateway::helpbrowserBuiltin(int, const Nelson::ListVector<Nelson::ArrayOf> &)
Nelson::EvaluateBuiltinCatchRuntimeException(Nelson::Evaluator *, void *, const Nelson::ListVector<Nelson::ArrayOf> &, int, unsigned __int64, bool)

Please also notice that if I comment in QArrayDataPointer
(Qt\6.6.0\msvc2019_64\include\QtCore\qarraydatapointer.h)
line 104 free(d)

It works in debug mode

JonB

@Nelson-numerical-software
Just because something does work in different versions of Qt or between release and debug mode does not mean that code is correct. Bugs show up (or don't show up) under many different circumstances.

I would start by concentrating on the question about whether you may be accessing the UI from a secondary thread. We have seen this countless times in people's code, even when they claim not to be doing so. Try your code without threads? Produce some minimal example which illustrates the crash?

Nelson numerical software

@JonB

Sure ;)

When you invest in Qt for a long time. You can also expect to no have some breaking change without visible warnings :p

Anyway it was not a complaint. It was just that I constated Qt6.2, 6.5 works in these cases and not 6.6.0

I will survey the class QArrayDataPointer and previous tickets fixed in Qt6.6.0 about it.

Thanks for your help

Christian Ehrlicher

QArrayDataPointer is a fundamental piece of a lot of basic qt classes. I doubt you found a bug in there. You do something wrong with your threading.

JonB

@Nelson-numerical-software said in My Qt 6.6.0 code crashs in debug mode (~QArrayDataPointer()) and not on release on Windows:

When you invest in Qt for a long time. You can also expect to no have some breaking change without visible warnings :p

That is true if your code is correct. However, if your code has some "fault" which has not shown up before and happens to go wrong now with a change of environment this happens. And it is the case that where a threading issue is involved you never know what changed circumstances may make it appear. It is the same with any code, nothing to do with Qt.

Nelson numerical software

Thank you for these comprehensive comments. :)

Great work from the developers for this 6.6.0 with many new features.

I have my answer

Christian Ehrlicher

Your pragma(lib) stuff in dllmain.cpp is wrong. You must not mix debug and release libraries on windows. I would remove this MSVC only stuff and let do cmake the correct things.

Nelson numerical software

@Christian-Ehrlicher said in My Qt 6.6.0 code crashs in debug mode (~QArrayDataPointer()) and not on release on Windows:

Your pragma(lib) stuff in dllmain.cpp is wrong. You must not mix debug and release libraries on windows. I would remove this MSVC only stuff and let do cmake the correct things.

I confirm that it was the trouble

on windows debug build must be linked with Qt debug library

Thanks for your time and investigations

OnkarP

Can you explain what you changed to fix this issue ?
As I am also facing the similar problem. I am using already built MSVC 2019 64 bit compiled libraries from QT 6.6.3 with VS 2022 C++ 64 bit application. My application is wrote for Debug and Release configuration. In both modes the crash is happening.

KeithS

Thanks @Nelson-numerical-software I had the exact same problem too. Easy mistake to make in Visual C++ when updating Qt versions and modifying linker input file list.

Christian Ehrlicher

@KeithS said in My Qt 6.6.0 code crashs in debug mode (~QArrayDataPointer()) and not on release on Windows:

and modifying linker input file list.

That's the reason to use a build system like e.g. CMake.

WaldemarH

Hi guys. I just came to the same issue on 6.8.2 where even the code below crashes on exactly the same space as above where the code run perfect before. So what changed... the build was done on w10 (months ago) and then after a format w11 was installed with a clean VS2022 installation. Since this happened qt crashes all the time. Now project didn't change so w10->w11 transition has to be the culprit. I'll edit this post after I'll rebuild 6.8.2 on w11.

int main( int argc, char *argv[] )
{
QVector<JSON_Object> value_object_list;

JSON_Object		e1;
JSON_Object		e2;
JSON_Object		e3;
JSON_Object		e4;
JSON_Object		e5;

value_object_list.append( e1 );
value_object_list.append( e2 );
value_object_list.append( e3 );
value_object_list.append( e4 );
value_object_list.append( e5 );

Christian Ehrlicher

Don't mix debug and release libraries.

snyang

I found one of my debug dll was compiled by using runtime library MultiThreadedDLL.
After change C/C++ -> runtime library as MultiThreadedDebugDLL in visual studio, the problem is gone.

Use the tool Dependencies, I can see the bad dll is using:

And the good dll is using:

WaldemarH

Created a new project, build it and all was fine (the same code). And as stated above the reason was mixing of debug/non-debug libraries.
Now the whole issue as it looks occurred when that Project->Options->Advanced->Use Debug Libraries was set to No (in all VS versions I have never set this value to anything.. I assume it came with VS22). Which caused that Compiler->Code Generation->Runtime libraries switched to non-debug version in the background.

So the solution is to switch the 'Use Debug Libraries' to true and all will be ok.