My Qt 6.6.0 code crashs in debug mode (~QArrayDataPointer()) and not on release on Windows
-
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
@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
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?
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
-
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
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.
-
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
@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 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.
Thank you for these comprehensive comments. :)
Great work from the developers for this 6.6.0 with many new features.
I have my answer
-
N Nelson numerical software has marked this topic as solved on
-
Thank you for these comprehensive comments. :)
Great work from the developers for this 6.6.0 with many new features.
I have my answer
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.
-
H human99 referenced this topic on
-
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.
@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
-
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. -
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.
@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.
-
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 ); -
Don't mix debug and release libraries.
-
I found one of my debug dll was compiled by using runtime library
MultiThreadedDLL.
After change C/C++ -> runtime library asMultiThreadedDebugDLLin visual studio, the problem is gone.Use the tool
Dependencies, I can see the bad dll is using:
And the good dll is using:
-
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.
