QTBUG-141579 deadlock protector crashes the app.

Andy314

Hello
I work with Qt 6.12.0 for Android.
that I found in the net.

[REG 6.8.3 -> 6.10.1] android-9-x86-on-linux: Failed to acquire deadlock protector for 'QAndroidPlatformOpenGLWindow::eglSurface()' while already locked by 'QAndroidInputContext::runOnQtThread()'

Any solution or work arounds for it ?

Andreas

Andy314

Here text from the KI to this context:

There are indeed concrete approaches and discussions within the Qt project to address this bug complex surrounding Android thread synchronization (QAndroidInputContext vs. GUI thread)—though the path forward is technically challenging.
What the Qt developers are working on under the hood

In the Qt bug tracker and Gerrit code reviews, there are several fundamental approaches for these types of Android deadlocks (QTBUG-141579 and similar):

Decoupling IME calls (Async IME):

Currently, the Android Java UI thread synchronously waits for a response from the Qt C++ thread when processing IME events (such as Backspace/composing updates). If Qt simultaneously starts a new event loop in the GUI thread (exec()), both threads freeze up. The developers' goal is to handle almost all calls between Java and C++ fully asynchronously via event queues.

Refactoring the DeadlockProtector lock:

The crash itself (SIGABRT, failed to acquire deadlock protector) is a built-in protective mechanism in Qt designed specifically to prevent the app from freezing indefinitely. Developers are working on modifying the locking logic for eglSurface window switches so that pending keyboard events are discarded or buffered instead of forcefully crashing the app.

The Challenge: Why it takes time

Android 14+ Restrictions: Google drastically tightened threading and focus handling for keyboards (IME) in recent Android versions. Behavior that "accidentally" worked in older Qt versions is now strictly blocked by Android.

Architecture of QDialog::exec(): On desktop systems, exec() is unproblematic. On mobile platforms (Android/iOS), nested/secondary event loops inherently clash with the native operating system lifecycle.

Conclusion & Outlook

Qt developers are actively working on these race conditions inside the Android platform plugin. However, because these fixes touch core system architecture, they are usually integrated incrementally across major releases.

The developer community therefore strongly recommends avoiding synchronous exec() calls altogether in UI code for Android, opting instead for asynchronous dialogs (dlg->open()) or screen switching (QStackedWidget).

SGaist

Hi,

Using open instead of exec has been encouraged on desktop as well for quite a long time due to nested event loops issues.