Resolve an issue that was causing xfwm4 on Arch to coredump

[s0600204]

(For the record, I run the xfce4 desktop environment on Arch Linux, and I am fully up-to-date. I reset LiSP to the latest dev/0.6 state, and disabled/removed all custom code/plugins.)

I've recently been having a problem with running LiSP on my computer.

Specifically: almost every time I try to open LiSP's Application Preferences dialog, xfwm4 (xfce4's window manager) would coredump and restart. Also, LiSP would stop responding to user input.

After two days of debugging, I traced this to the change you see in the diff.

I'm not 100% sure why this should fix the issue, but I suspect it might be a race condition. Reasoning:

• In the process of debugging, it came up that the underlying GDK system interacts with the the X Windowing System asynchronously.
• Starting xfwm4 like so: GDK_SYNCHRONIZE=1 xfwm4 --replace (which tells GDK to interact with X synchronously) resolved the issue (at the cost of performance).
• When _currentWidget is shown then added to a parent widget, then (in theory) _currentWidget is being laid out/drawn twice: once with no (or a "default") parent, then again with the correct parent:
  • With X Window-interactions run synchonously, the first layout/draw command completes (and returns) before the second one is issued.
  • With X Window-interactions run asynchronously (the default), the second layout/draw command might be received by X before the first one is complete, invalidating it.
• By adding _currentWidget to a parent before making it shown, there's only one draw - and with the correct parent.

Maybe.

All I know, is that this appears to fix my problem, and I can now open the Application Preference dialog without xfwm4 throwing a wobbler.

[FrancescoCeruti]

Weird issue :thinking: your conclusion it's probably correct.

I cannot reproduce the issue in gnome (on Xorg) so I think the issue lies somewhere with xwfm4.

Since a Qt widget without a parent will get its own window, we are asking to create a window but then to destroy it almost at the same time, so, as you said probably a race condition where some thread/process tries to access some invalid reference.

Anyway, the change makes perfect sense, so it's okay :+1: Thanks