Solved Why does even a basic QTreeWidget app crash on QTreeWidget::clear() ???
-
@jsulm
It turns out that on my Windows 7 machine, Qt 5.9.1 ALWAYS crashes in Debug mode when the program reaches adelete
instruction, no matter which example I try. -
I submitted this as a bug
https://bugreports.qt.io/browse/QTCREATORBUG-19007 -
@Diracsbracket I highly doubt this is an issue with Qt, so submitting as a bug will just end in it being non-reproducible.
It almost sounds like you have a bad version of ntdll. My guess would be that you have some bad software/update from MS on your system.
It could be some other piece of software you have interfering too. A virus checker perhaps? SpyBot seems to cause an issue like this based on some light searching I did.
If you try this same thing on a virtual machine with windows 7 it should work perfectly. Finding what is causing it is a much bigger challenge than I'm able to tackle remotely though. :)
And it most definitely is the same problem you mentioned in your other thread.
-
@ambershark
Thanks. It seems no one else is complaining about this, so it must be my system... If it gets solved, I'll post an update. -
@Diracsbracket An easy test would be to setup a virtualbox vm with a fresh windows and install Qt. Then test your app in there. If it works then you know it's a problem on your system with something you have installed. If it does it there too, there may be more to it. Maybe hardware, or maybe there is a legit Qt bug.
That would be a major bug though and would definitely have been caught before release. It would also affect all of us and not just you.
-
@ambershark
Exactly. That's why I am gonna put this post to "Solved". I don't really have the time right now to setup another VM with Windows 7 + Qt Creator + Visual Studio, but I'll give it a try in my Windows 10 VM, although it's a different environment altogether.
Cheers! -
Update: tried in a Windows 10 VM. Same error. Debugging just does not work.
Installed Visual Studio 2015, Qt 5.9.1, and SDK kit 10 for the debugging tools.What a WASTE of time!!!!
-
@Diracsbracket Well it wasn't a waste of time since it gave you more information about the problem. So if you set up a fresh windows vm and still had the issue then it is something to do with what you are installing in the vm.
What software did you install in your fresh environment? Exact list.
Also have you tried with a different Qt version, maybe a bug was introduced in 5.9.1, although I doubt something that major would have made it through QA.
One more thing too, have you tried using a model instead of parenting QTreeWidgetItem's to the tree? You can use a QStandardItemModel which should do the same thing you are doing. See if the crash is still there. This is a stretch though since it's only in debug it's unlikely there is an issue here.
Tomorrow when I have time I'll try to throw your code into a quick test app and see if it crashes for me.
-
The problem I am facing is not limited to the simple QTreeWidget example I posted, but with every standard Qt example, always at some delete operation.
I have tried installing the latest Windows Kit 10 release (10.0.16299.15) with the new cdb.exe, whose version is wrongly reported by Qt Creator (when mouse hovering over the file, the tooltip shows the correct version, but the text field of Qt Creator remains wrong, even after restart of PC). The new Kit release does not solve the problem.
Now, I am installing Qt 5.9.2, which as you know, takes some time... even at 1.5 MB/s ...
-
-
Are you building the (debug) Qt from the sources yourself?
-
What happens if you run the debug-built app outside of Qt Creator/debugger, e.g. from command-line?
-
-
@JNBarchan
I am not using a self-built version of Qt Creator, just using the official windows installer.I just now uninstalled all of Qt, and installed 5.9.2... And of course, I get errors which I didn't have before:
D:\Qt\5.9.2\msvc2015_64\include\QtCore\qt_windows.h:64: error: C1083: Cannot open include file: 'windows.h': No such file or directory
Qt is just great...
-
@Diracsbracket said in Why does even a basic QTreeWidget app crash on QTreeWidget::clear() ???:
Qt is just great...
It is.
After installing Qt did you delete the build folder, run qmake and rebuild? -
@jsulm Yes...
-
I finally got the debugging working again. I have no solution, because I still don't know what the cause of my problems was, but I reinstalled Qt 5.9.1, uninstalled VS2015 and reinstalled it. And now debugging works again. Moreover, I no longer need have the following lines in my .pro files:
INCLUDEPATH += "C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt" LIBS += "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\ucrt\x64\ucrt.lib" LIBS += "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\ucrt\x64\ucrtd.lib"
I needed to add those lines in every .pro file of my earlier install, otherwise none of the Qt examples nor my program would build. That probably was already an indication that there was something wrong with my installation and why I couldn't debug. Now, my little program (and I guess all the Qt examples too) builds without those lines.
Cheers to all who tried to help!
-
@Diracsbracket said in Why does even a basic QTreeWidget app crash on QTreeWidget::clear() ???:
I finally got the debugging working again. I have no solution, because I still don't know what the cause of my problems was,
If you played with the versions of the C runtime libraries, but did not think to mention it, do you not think that might be related to why it falls over in
delete
callingcalloc
callingHeapValidate
?I wouldn't read much into it crashing until you are 100% sure your libraries --- Debug-or-not --- are definitely all correct & consistent across everything you're doing. Personally.
-
@Diracsbracket said in Why does even a basic QTreeWidget app crash on QTreeWidget::clear() ???:
I finally got the debugging working again. I have no solution, because I still don't know what the cause of my problems was, but I reinstalled Qt 5.9.1, uninstalled VS2015 and reinstalled it. And now debugging works again. Moreover, I no longer need have the following lines in my .pro files:
INCLUDEPATH += "C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\ucrt" LIBS += "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\ucrt\x64\ucrt.lib" LIBS += "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\ucrt\x64\ucrtd.lib"
I needed to add those lines in every .pro file of my earlier install, otherwise none of the Qt examples nor my program would build. That probably was already an indication that there was something wrong with my installation and why I couldn't debug. Now, my little program (and I guess all the Qt examples too) builds without those lines.
Cheers to all who tried to help!
Lol this would have been great to know at the beginning. You did something very wrong with your environment or install if you had to do this. And of course you were then mixing C runtimes which of course is not ok, as you found out. I'm surprised all you did was crash on delete to be honest. It should have been much worse.
Oh well, you learned something which is the whole point of these forums. :) Glad you got it fixed.
-
@JNBarchan said in Why does even a basic QTreeWidget app crash on QTreeWidget::clear() ???:
If you played with the versions of the C runtime libraries, but did not think to mention it, do you not think that might be related to why it falls over in delete calling calloc calling HeapValidate?
I added those lines because after installing Qt Creator and selecting the auto-detected compilers etc..., it would not build because of some crt header file not being found. A proposed solution I found on the web was to add those lines in the .pro file, which seemed to work, at least for the release builds. That's why.
-
@Diracsbracket
I don't dispute that you (felt you) had whatever reason to add the stuff. But as @ambershark & I observed, when you come reporting a heap crash in a post entitled "Why does even a basic QTreeWidget app crash on QTreeWidget::clear() ???", you have to let us know that your "basic QTreeWidget" was generated using a system where you had to tinker with compiler/linker settings from the default as that is 100% germane....