In the QmitkProgressBar qApp->processEvents is called which is rather bad and I don't see the reason for that. This may have the effect that an event is overwritten even if it is currently processed. E.g. this was the cause of T12441.
I think this is a good time to generally think about a redesign of our progress bar.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | None | T16217 Error/crash in run segmentation while already processing | ||
| Resolved | None | T13180 QmitkProgressBar is messing around with qt event loop |
Event Timeline
Comment Actions
I agree that the progress bar design is not optimal.
However, the real problem with T12441 was (in my opinion) the usage of a static member variable (mitk::EventMapper:m_StateEvent) containing a mitk::Event pointer (m_Event) which is set to stack-allocated objects from different event handling routines.
Comment Actions
Yes, I added the RFD keyword.
I recently came across the following problem:
A synchronous long running operation frequently updated the MTIK progress bar. Because the progress bar calls qApp->processEvents(), the GUI was responsive, "emulating" asynchronous behaviour of the operation. This enabled the user to start the same operation again, which was actually not designed to be called "recursively".
So I vote for removing qApp->processEvents() because of unforeseeable side-effects.
Comment Actions
FYI, our application becomes unusable (linux) and/or crashes (windows) and we think it is because of this bug. As Sascha pointed out, the same operation can be started again.
Comment Actions
This bug could not be fixed within the 2013-06 release and has medium severity. Setting target milestone to unspecified.
Comment Actions
This bug can cause a lot of other bugs, since the responsivity of the gui during execution of an operation occurs nearly everywhere. Setting importance to high critical since otherwise we might get flooded with related bugs.
Comment Actions
To generate a quick solution to prevent the application from crashes due to restarting operations while they are running, the qApp->processEvents() call was removed from the QmitkProgressBar implementation.
This causes the scene loading to be not displayed in the progress bar, but it eliminates the application crashes.
Adding new T16246, to make the progress bar react on scene reading.
Adding new T16247, to further discuss a better solution for the progress bar implementation.
Comment Actions
[f90374]: Merge branch 'bug-13180-RemoveEventProcessingFromProgressBar'
Merged commits:
2013-10-09 17:22:22 Sven Mersmann [cf1b01]
Remove qApp->processEvent() from QmitkProgressBar due to crashes during long running operations.This call was responsible for triggering a restart of the operation while the operation was running.