Upon failed assertion in threaded computation, message box is not shown correctly

To reproduce, manipulate e.g. the ASSERT in Base/Progress/ProgressHandler.cpp, and run a simulation.

The message box will pop up so briefly that it cannot be read, then the GUI will terminate. The following is written to the terminal:

FATAL: Assertion m_inform failed in /G/sw/ba/Base/Progress/ProgressHandler.cpp, line 21
QObject::setParent: Cannot set parent, new parent is in a different thread
WARNING: QBackingStore::endPaint() called with active painter; did you forget to destroy it or call QPainter::end() on it?

TODO: Upon launching a computation thread, call qInstallMessageHandler to install an appropriate message handler.

One possibility: Wrap the threaded computation by a try block. Let the message handler throw a standard exception.

Threads appear in

• single calculation
• fit
• saving data field

mentioned in merge request !1393 (merged)

added bug label

marked this issue as related to #340 (closed)

mentioned in issue #340 (closed)

assigned to @m.svechnikov

mentioned in merge request !1502 (closed)

changed the description

global variables and a magic string ... please let us think about alternative designs before rushing this.

With extant code, control reaches and briefly displays the message box in App/MessageHandler.cpp. The problem is but with the three lines

        msgbox.exec();
        qApp->quit();
        exit(1);

How about enclosing these lines in a mutex?

Seems that the core of the problem is "incompatibility" of __FILE__ and any other text in message for QMessageBox.

So if in Assert.h we exclude __FILE__

msg << "Assertion " << (#condition) << " failed in " /*<< __FILE__*/ << ", line " << __LINE__;

then everything works regardless of the presence of threads:

If in Assert.h we exclude everything but __FILE__

msg << __FILE__/;

then everything works again:

But for some strange reason we cannot combine __FILE__ with anything else, the problem appears for both QThread and std::thread. And nothing helps here, including mutex.

I'm out of ideas how to join these char sequences and pass into a QMessageBox.

In the worst case, if this problem is not solved in the coming days, before the release, I suggest using the solution !1502 (closed) (which should be finished then).

I agree that it is not a good style thing, so it can be added to release branch but not to main branch for not contaminating the code.

I confirm your observation - but it has nothing to do with __FILE__. If I replace __FILE__ by "0123456789012345678901234567890123456789", I get the same crash. So the crash happens iff the message passed to the QMessageBox exceeds a certain length.

From a discussion on Stackoverflow and from a web search for "qmessagebox from thread" (e.g. https://forum.qt.io/topic/32255/pop-up-a-qmessagebox-from-a-qthread) it appears that QMessageBox must not be called from a thread. The recommended solution is to emit a signal from the subthread, and launch the QMessageBox from the GUI main thread.

Here are the minimal examples.

• "no_problem" example:

If we obtain __FILE__ in main.cpp and use threads also in main.cpp everything works in any combination.

no_problem.tar.gz

• "problem" example:

If we obtain __FILE__ in source.cpp and use threads also in main.cpp then only combination "thread + __FILE__ + some other text" is problematic.

problem.tar.gz

The recommended solution is to emit a signal from the subthread, and launch the QMessageBox from the GUI main thread.

This is a way of !1502 (closed), where we emit exceptions and pass them until GUI main thread is reached.

Please wait. I will make a counterproposal with everything through exceptions; no more qFatal, no more QMessageHandler.

mentioned in merge request !1518 (merged)

mentioned in commit ce832e20

Mostly solved. Remainings tasks now in #546 (closed).

closed

mentioned in issue libqcr#7 (closed)