Bug 260437 - x11-wm/skippy-xd: remove wrong assertion
Summary: x11-wm/skippy-xd: remove wrong assertion
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexey Dokuchaev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-15 13:47 UTC by Michael Zhilin
Modified: 2022-01-19 07:01 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (danfe)


Attachments
Git format-patch (1.05 KB, patch)
2021-12-15 13:47 UTC, Michael Zhilin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Zhilin freebsd_committer 2021-12-15 13:47:52 UTC
Created attachment 230140 [details]
Git format-patch

Hi,

Skippy XD crashes on assertion: assert(!XEventsQueued(ps->dpy, QueuedAfterReading));

Assertion checks that queue is empty after XSync. But new events can come like:
[   109.28 ] Event PropertyNotif wid 0x000006fc (Root)

It looks like assertion is wrong and to be removed.
As quick fix, patch removes assertion. 

The upstream looks like dead, so patch wasn't submitted to upstream.
Comment 1 Alexey Dokuchaev freebsd_committer 2022-01-04 03:17:47 UTC
(In reply to Michael Zhilin from comment #0)
> Skippy XD crashes on assertion: assert(!XEventsQueued(ps->dpy, QueuedAfterReading));
Hmm, I'm actively using skippy-xd (under Openbox and IceWM) since the day I've resurrected the port and had never seen it crash.  Which is your working environment?  What are the steps to reliably reproduce the problem?

> It looks like assertion is wrong and to be removed.
We don't know that yet, it could actually point to the bug elsewhere in the stack.

> The upstream looks like dead, so patch wasn't submitted to upstream.
That's fine, we maintain it locally in the Ports Tree.
Comment 2 Michael Zhilin freebsd_committer 2022-01-19 07:01:04 UTC
My apologies for late answer, just noticed questions.

I appreciate your work and thank you for port resurrection. 

> What are the steps to reliably reproduce the problem?
Actually I don't remember conditions. 

> Which is your working environment? 
jwm 2.3.7_1, xorg-7.7_3, 14.0-current. 

> We don't know that yet, it could actually point to the bug elsewhere in the stack.
I doubt so. Event can come just after flush of queue and before assertion like in example:
[   109.28 ] Event PropertyNotif wid 0x000006fc (Root)

As well, I didn't find any logic relying on this assertion. So assertion looks like "nice to have" causing race condition crashes.