Bugzilla – Bug 5977Race condition: applications started during OB startup hangs until additional events are generatedLast modified: 2013-06-27 17:31:35 EDT
This is a read-only, static archive of bugzilla.icculus.org
Bug 5977
- Race condition: applications started during OB startup hangs until additional events are generated
Created attachment 3362[details]
Shell script which triggers the bug
If an application starts during a particular time of the OpenBox startup, it will hang and will not be displayed. In particular, this happens if you launch the application just after OB has set the _NET_SUPPORTING_WM_CHECK property. For an example, see the attached shell script in conjunction with this patch, to reliably reproduce the problem:
--- a/openbox/screen.c
+++ b/openbox/screen.c
@@ -201,6 +201,10 @@ gboolean screen_annex(void)
pid = getpid();
OBT_PROP_SET32(obt_root(ob_screen), OPENBOX_PID, CARDINAL, pid);
+ XSync(obt_display, FALSE);
+ fprintf(stderr, "ob: Before setting _NET_SUPPORTING_WM_CHECK\n");
+ sleep(5);
+
/* set supporting window */
OBT_PROP_SET32(obt_root(ob_screen),
NET_SUPPORTING_WM_CHECK, WINDOW, screen_support_win);
@@ -210,6 +214,10 @@ gboolean screen_annex(void)
OBT_PROP_SET32(screen_support_win, NET_SUPPORTING_WM_CHECK,
WINDOW, screen_support_win);
+ XSync(obt_display, FALSE);
+ fprintf(stderr, "ob: after setting _NET_SUPPORTING_WM_CHECK\n");
+ sleep(5);
+
It is recommended to run the shell script with a clean Xserver such as Xvnc with no other X11 clients attached, ie:
DISPLAY=:50 trig.sh
In this case, xclock will be launched, but nothing will be displayed until you "do something else". This could be a keyboard or mouse input, or launch of another application.
My guess is that the problem is in xqueue.c. This code is quite complex.
I've been seeing what's probably the same bug on newer Linux distros: the xterm I start in my .xinitrc just before launching openbox doesn't map until I do a mouse click. It's somewhat sporadic: it happens every time on the first launch of X after booting, but not every time if I quit X and restart. I've tried putting in delays (like (sleep 5; xterm) & in .xinitrc) but it makes no difference.
As a workaround (Mikachu's suggestion), I'm running X as:
startx -- -dumbSched
I haven't seen the problem once since I started doing that. I don't know if there are any disadvantages (performance issues?) with dumbSched.
Created attachment 3362 [details] Shell script which triggers the bug If an application starts during a particular time of the OpenBox startup, it will hang and will not be displayed. In particular, this happens if you launch the application just after OB has set the _NET_SUPPORTING_WM_CHECK property. For an example, see the attached shell script in conjunction with this patch, to reliably reproduce the problem: --- a/openbox/screen.c +++ b/openbox/screen.c @@ -201,6 +201,10 @@ gboolean screen_annex(void) pid = getpid(); OBT_PROP_SET32(obt_root(ob_screen), OPENBOX_PID, CARDINAL, pid); + XSync(obt_display, FALSE); + fprintf(stderr, "ob: Before setting _NET_SUPPORTING_WM_CHECK\n"); + sleep(5); + /* set supporting window */ OBT_PROP_SET32(obt_root(ob_screen), NET_SUPPORTING_WM_CHECK, WINDOW, screen_support_win); @@ -210,6 +214,10 @@ gboolean screen_annex(void) OBT_PROP_SET32(screen_support_win, NET_SUPPORTING_WM_CHECK, WINDOW, screen_support_win); + XSync(obt_display, FALSE); + fprintf(stderr, "ob: after setting _NET_SUPPORTING_WM_CHECK\n"); + sleep(5); + It is recommended to run the shell script with a clean Xserver such as Xvnc with no other X11 clients attached, ie: DISPLAY=:50 trig.sh In this case, xclock will be launched, but nothing will be displayed until you "do something else". This could be a keyboard or mouse input, or launch of another application. My guess is that the problem is in xqueue.c. This code is quite complex.