The application frame (empty window) is shortly shown before the application crashes without the chance to hook up with the debugger. However, the console prints:
QWidget: Must construct a QApplication before a QWidget
QWaitCondition: Destroyed while threads are still waiting
This error started occurring with the latest BlueBerry changes. Release config starts, only debug config has this issue.
This bug only occurred a few times but when it did, it was persistent at least for the day it occurred (Heisenbug-style, yay :/). Lowered importance to "critical" until we found a setup to reproduce this T100%.
We are experiencing exactly this issue.
It's impossible for us to run a debug build, which is a pity, because our own perspective broke with the new mitk version and now we are unable to debug the problem.
If you need additional information please let me know.
Best regards
Florian
If you can reproduce this crash with the current 2015.05.2 release, a complete stack trace would be helpful. Ideally, a stack trace for each thread involved.
I can do that, but could you tell me how to save the output, so it's of any use for you?
Or is there a tutorial how to export the stacktrace?
Best regards
Florian
Did some debugging and what I found out so far was:
The problem seems to be in the method:
IWorkbenchWindow::Pointer Workbench::BusyOpenWorkbenchWindow
newWindow->Create(); // must be created before adding to window
Tries to create a window, (in fact a window appears and it is immediately closed).
And the line:
try
{
newWindow->BusyOpenPage(perspID, input);
}Finally leads to the error message on the console:
QWidget: Must construct a QApp....
If I know how to export the stack trace in a usable manner, I can provide it as well.
A text export would be enough to get started. I don't want to get into the crash dump business just yet.
In the Visual Studio stack trace windows, you can select all frames (list items) by pressing ctrl-a and copy them into a text file (using ctrl-c). You would have to do this for each thread. Maybe there is a better way, but I just know this one.
Here is the output:
http://pastie.org/private/rmrni2tdavdgbmckdsgdra
It shows me only one process and frame.
Additionally I found out that the superbuild seems to run smoothly.
Right now I'm trying to figure out, which part of our specific configuration may cause the issue.
I guess it had something to do with our selfcompiled VTK and GDCM.
Right now it is working fine at our site.
One additional commit.
The patch.exe which is downloaded crashes on every system we have tested.
Therefore, we have to specify an alternative patch.exe otherwise the superbuild fails immediately.
Your stack trace shows a mix of debug and release DLLs. This is always asking for trouble.
When building VTK yourself, you need to make sure that your PATH env variable which is picked up my the MITKWorkbench process does contain the correct directories. Especially not mixing debug and release DLLs.
For your patch.exe problem, can you please enter a new bug with the following information:
That is interesting to know, that was absolutely not intended and surely was the root of our problems.
From which part of the stack trace were you able to extract this information?
Concerning the executable. The checksum is:
ead4ac670863ad2efa1bdf03a6caa374 *patch.exe
The version that worked for us was from our git enviroment, which I had downloaded here:
Many toolkits (e.g. Qt) append a "d" to the library name of the debug versions. Your stack trace contains a mixture of "Qt5Core.dll" and "Qt5Cored.dll" for example (being loaded via different dependency chains).