Bug 359467

Summary:	KWin might cause recursive QXcbEventReader::lock()'s
Product:	[Plasma] kwin	Reporter:	Thomas Lübking <thomas.luebking>
Component:	core	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	juergen.scholz.84, kde
Priority:	NOR
Version First Reported In:	git master
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Backtrace by Jürgen Scholz, originating from unrelated bug #358245

Description Thomas Lübking 2016-02-16 15:07:48 UTC

QXcbEventReader uses a non-recursive mutex (one might call this begging for trouble, but well...) and KWin calls QX11Info::getTimestamp() when activating a window after the active window closed (see backtrace)

This sucks a bit, we either need to defer activation to the end of the eventloop (bad idea, since we're gonna loose the formerly active client until then) or avoid fetching the X11 timestamp while we're in the eventloop.
Latter will inevitably collide w/ any solution reg. bug #348569 *AND* it's pretty hard to assure we're not causing other access to the eventreader from the eventfilter.

=> Maybe ask Qt to use a recursive mutex in 5.6?
Other ideas?

Reproducible: Always

Comment 1 Thomas Lübking 2016-02-16 15:10:10 UTC

Created attachment 97250 [details]
Backtrace by Jürgen Scholz, originating from unrelated bug #358245

The backtrace that made me aware of the problem, it's not related to the bug it was originally filed on.

Comment 2 Martin Flöser 2016-02-17 07:20:11 UTC

(In reply to Thomas Lübking from comment #0)
> => Maybe ask Qt to use a recursive mutex in 5.6?

Sounds like the best idea. The API Qt offers shouldn't dead-lock in a correct usage.

Comment 3 Thomas Lübking 2016-02-17 23:15:32 UTC

They might argue that our "correct usage" is a native event filter ;-)

Maybe we'll have to -steal- "borrow" QXcbConnection::getTimestamp()

Comment 4 Martin Flöser 2016-02-18 07:23:22 UTC

(In reply to Thomas Lübking from comment #3)
> They might argue that our "correct usage" is a native event filter ;-)
> 
> Maybe we'll have to -steal- "borrow" QXcbConnection::getTimestamp()

No need to steal, I wrote the code (9c45260942c0ee32267e651d981bfa33a6acb64d) ;-) And the reason for that was that it's impossible to implement it in a native event filter (at least back then).

Comment 5 Justin Zobel 2021-03-10 00:32:38 UTC

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.

Comment 6 Thomas Lübking 2021-03-10 07:12:41 UTC

No idea whether that's still reelvant, this "bug" discusses working around a threading issue in Qt's X11 code that existed in 2016

Comment 7 David Edmundson 2024-02-19 16:29:55 UTC

Lets assume not given we're talking about a hypothetical many years later