Bug 471927

Summary: Unexpected result from some APIs relates to X property
Product: [Fedora] Fedora Reporter: Kevin Fenzi <kevin>
Component: gtk2Assignee: Matthias Clasen <mclasen>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: bugzilla, che666, i18n-bugs, ktdreyer, mario, mclasen, pmr, tagoh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-18 16:35:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
proposed patch
none
try to unset _NET_SUPPORTING_WM_CHECK
none
simple test code none

Description Kevin Fenzi 2008-11-17 18:20:05 UTC
If the imsettings and imsettings-xfce packages are installed xfwm4 settings are confused and don't think xfwm4 is the window manager. 

1. Install imsettings-xfce
2. yum groupinstall XFCE
3. login and choose Xfce as your desktop. 
4. right click on the desktop
5. choose settings manager
6. choose either "Window Manager" or "Window Manager Tweaks". 
7. You will get a message:

"These settings cannot work with your current window manager (imsetting-xim)"

The code in xfwm4 hasn't changed in years here. It does: 

    wm_name = gdk_x11_screen_get_window_manager_name (gdk_screen_get_default ());
    if (g_ascii_strcasecmp (wm_name, "Xfwm4"))
    {
        xfce_err (_("These settings cannot work with your current window manager (%s)"), wm_name);
        return;
    }

Is imsettings changing the gdk default window manager somehow?

Removing imsettings causes everything to work as normal.

Comment 1 Rudolf Kastl 2008-11-17 18:25:18 UTC
i can reproduce that on current rawhide. actually if you start the same setting application: xfce-setting-show in the gnome session it would return the correct property 

"These settings cannot work with your current window manager (metacity)"

Comment 2 Akira TAGOH 2008-11-18 04:32:30 UTC
Hmm, strange. I can reproduce here too though, X property looks sane:

$ xprop -root | grep _NET_SUPPORTING_WM_CHECK
_NET_SUPPORTING_WM_CHECK(WINDOW): window id # 0x1e00062
$ xprop -id 0x1e00062 | grep _NET_WM_NAME
_NET_WM_NAME(UTF8_STRING) = 0x58, 0x66, 0x77, 0x6d, 0x34

Property is certainly set Xfwm4 but it complains me "There settings cannot work with your current window manager (imsettings-xim)" as you said. however imsettings definitely doesn't touch that property at all. I'm not really sure where Xfwm4 gets it from.

Comment 3 Mario Heininger 2008-11-18 09:04:43 UTC
same Problem here. I can reproduce the Bug in 32Bit and 64Bit Environment.

Comment 4 Akira TAGOH 2008-11-18 09:21:32 UTC
Okay, I've tracked down this issue and the problematic code was in gtk+. gtk+ uses XGetWindowProperty to obtain the value assigned to certain X property. it specifies an offset and a length of value in X property. in man page, that says:

long_length
        Specifies the length in 32-bit multiples of the data to be retrieved.

And the problematic code in gtk+ does give G_MAXLONG as long_length. it will causes an overflow to negative. then it returns the unexpected result.

Comment 5 Akira TAGOH 2008-11-18 09:23:18 UTC
Created attachment 323868 [details]
proposed patch

confirmed a fix with this patch. it contains fixes for similar problematic code.

Comment 6 Kevin Fenzi 2008-11-19 23:31:55 UTC
Matthias: any chance this could go out as a F-10 0 day update? At least to updates-testing? 

Or is this too invasive a fix?

Thoughts?

Comment 7 Matthias Clasen 2008-11-21 01:32:53 UTC
I agree that using LONG_MAX here seems like a bad idea. 

But it seems not sufficiently explained how imsettings-xim manages to trigger this problem here.

Do we actually get a BadValue error ? 

Also needs to be filed upstream, too.

Comment 8 Akira TAGOH 2008-11-25 09:08:01 UTC
Hmm, just putting a debugging message to see what happens with XGetWindowProperty in gtk+ made it working. also with -3, I can't reproduce this issue with "Window Manager Settings" from the menu. but "Window Manager Tweaks" introduces the above error. I have no idea to reproduce this though, I saw "There settings cannot work with your current window manager (gnome-screensaver)" too.

FWIW no BadValue error.

Assuming the man page describes it correctly, it doesn't says prop_return will be NULL when something went wrong. so maybe should check if actual_type_return and actual_format_return is the expected value and nitems_return is more than 0, also bytes_after_return is 0?

Comment 9 Akira TAGOH 2008-11-25 12:46:43 UTC
For more information:

Sorry, the above was false alarm. and it races something. I've added the below code to see what value XGetWindowProperty returns in gdk_x11_screen_get_window_manager_name():

diff -pruN gtk+-2.14.4.orig/gdk/x11/gdkevents-x11.c gtk+-2.14.4/gdk/x11/gdkevent
s-x11.c
--- gtk+-2.14.4.orig/gdk/x11/gdkevents-x11.c    2008-10-17 13:06:37.000000000 +0
900
+++ gtk+-2.14.4/gdk/x11/gdkevents-x11.c 2008-11-25 19:40:42.000000000 +0900
@@ -2719,6 +2719,7 @@ gdk_x11_screen_get_window_manager_name (
                               &type, &format, 
                               &n_items, &bytes_after,
                               (guchar **)&name);
+g_print("%d: 0x%x, %d, %ld, %ld, %s\n", getpid(), screen_x11->wmspec_check_wind
ow, format, n_items, bytes_after, name);
           
           gdk_display_sync (screen_x11->display);
           
And this appears in .xsession-errors:

21550: 0xe00003, 8, 14, 0, imsettings-xim

pid 21550 is xfce-mcs-manager, which is reporting it. and imsettings-xim certainly owns window id 0xe00003, which was created as a communication window between client and server in XIM. there are no code to modify _NET_WM_NAME nor _NET_SUPPORTING_WM_CHECK in imsettings-xim though. and gtk+ has only code to modify _NET_WM_NAME. and window manager modifies _NET_SUPPORTING_WM_CHECK. actually just running X server and imsettings-xim doesn't create _NET_SUPPORTING_WM_CHECK on the root window.

Since this issue doesn't appear in metacity, I'm a bit suspecting xfwm4 behaves around it differently. looking at xfwm4 now.

Comment 10 Bug Zapper 2008-11-26 05:31:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Akira TAGOH 2008-11-27 06:31:42 UTC
I got a trick. the scenario is:

1. metacity runs on gdm. and metacity is set an own window id to
_NET_SUPPORTING_WM_CHECK.
2. the desktop session is going to start without restarting X server. and
metacity is gone. but _NET_SUPPORTING_WM_CHECK is still there, with invalid
window id.
3. imsettings-xim is running. it grabs same window id. thus, window id on
_NET_SUPPORTING_WM_CHECK is valid again. which isn't right.
4. xfce-mcs-manager is running before xfwm4. and the unexpected window id is
set to GDK_SCREEN_X11 (screen)->wmspec_check_window. it's cached during the
instance is alive. so gdk_x11_screen_get_window_manager_name() always returns
the unexpected name.


There are some points:

a. metacity doesn't delete _NET_SUPPORTING_WM_CHECK from the root window. it
may be dangerous since the window id could be reused.
b. invoking xfce-mcs-manager before xfwm4 may be not a good idea as long as it
uses gdk_x11_screen_get_window_manager_name(), because of caching the value.
it's still likely to return "unknown" if no _NET_SUPPORTING_WM_CHECK is set to
the root window and it's being cached before running xfwm4.
c. or using gdk_x11_screen_get_window_manager_name() in xfce-mcs-manager may be
not a good idea.
d. or caching the value in GdkScreen may be not a good idea.

Comment 12 Paul Michael Reilly 2008-12-15 02:21:47 UTC
FWIW, I've noticed that even after doing a yum remove on the imsettings package (and its dependencies) that I still have a problem with gnome-screensaver which is resolved by removing it and adding xscreensaver.  I'm not sure why I see this issue but no one else seems to have it.

Comment 13 Akira TAGOH 2008-12-15 03:21:39 UTC
(In reply to comment #12)
> FWIW, I've noticed that even after doing a yum remove on the imsettings package
> (and its dependencies) that I still have a problem with gnome-screensaver which
> is resolved by removing it and adding xscreensaver.  I'm not sure why I see
> this issue but no one else seems to have it.

As I've mentioned it at the above comment, the root cause is either of a or b or c or d. but this issue may be not gone completely with one fix only.

for example, if we have a fix for (a) only, you'll see "There settings cannot work with your current window manager (unknown)".
a fix for (b) only, there may be a side-effect if xfwm4 requires xfce-mcs-manager working.
a fix for (c) only or (d) only, there may be a side-effect so that there are still possibility that xfce-mcs-manager gets a window manager name from X property other than Xfwm4.

I suppose this issue may be gone completely with fixes for (a) and (b). or if some one is sure there are no side-effects with a fix of (c) or (d), we could go with it. but I'm not familiar with Xfce. so need feedbacks from Xfce wizards.

Comment 14 Matthias Clasen 2008-12-15 05:04:25 UTC
Akira, thanks for investing the time to track this down this far.

  3. imsettings-xim is running. it grabs same window id. thus, window id on
  _NET_SUPPORTING_WM_CHECK is valid again. which isn't right.

Have you confirmed that this is actually happening ? I'd be surprised if the X server recycled client ids that quickly, but it is of course possible...

  a. metacity doesn't delete _NET_SUPPORTING_WM_CHECK from the root window. it
  may be dangerous since the window id could be reused.

Worth filing a bug about. 

  b. invoking xfce-mcs-manager before xfwm4 may be not a good idea as long as it
  uses gdk_x11_screen_get_window_manager_name(), because of caching the value.
  it's still likely to return "unknown" if no _NET_SUPPORTING_WM_CHECK is set to
  the root window and it's being cached before running xfwm4.

If things work as expected, you'll get a window-manager-changed signal in xfce-mcs-manager when xfwm4 starts up, so this shouldn't be a problem. But you'll of course have to expect the warning 

 xfce_err (_("These settings cannot work with your current window
manager (%s)"), wm_name);

to trigger if you start xfce-mcs-manager earlier than xfwm4. And the manager needs to handle window manager changes correctly.

Comment 15 Matthias Clasen 2008-12-15 05:07:07 UTC
Btw, a simple workaround might be to scrub _NET_SUPPORTING_WM_CHECK using xprop, first thing in your session startup, before anything else.

Comment 16 Matthias Clasen 2008-12-15 05:32:13 UTC
Created attachment 326904 [details]
try to unset _NET_SUPPORTING_WM_CHECK

Does this metacity patch make things work for you ?

Note that this is only a best-effort patch, it will only help if metacity is shut down gracefully. If it is simply killed, it still leaves _NET_SUPPORTING_WM_CHECK behind.

Comment 17 Matthias Clasen 2008-12-15 05:40:52 UTC
Filed upstream:
http://bugzilla.gnome.org/show_bug.cgi?id=564561

Comment 18 Akira TAGOH 2008-12-15 06:05:41 UTC
(In reply to comment #14)
> Akira, thanks for investing the time to track this down this far.
> 
>   3. imsettings-xim is running. it grabs same window id. thus, window id on
>   _NET_SUPPORTING_WM_CHECK is valid again. which isn't right.
> 
> Have you confirmed that this is actually happening ? I'd be surprised if the X
> server recycled client ids that quickly, but it is of course possible...

Yes, I have. it was surprised to me too. please try the simple testing code I'll attach later.

>   a. metacity doesn't delete _NET_SUPPORTING_WM_CHECK from the root window. it
>   may be dangerous since the window id could be reused.
> 
> Worth filing a bug about. 

Sure. filed to Bug#476481 and upstream too (see reference in that bug).

(In reply to comment #15)
> Btw, a simple workaround might be to scrub _NET_SUPPORTING_WM_CHECK using
> xprop, first thing in your session startup, before anything else.

Yes, I did similar thing in a hook of XChangeProperty with LD_PRELOAD to track it down accurately.

Comment 19 Akira TAGOH 2008-12-15 06:12:39 UTC
Created attachment 326906 [details]
simple test code

% ./a.out
opening a display: f23010
creating a window: 5c00001
destroying a window
closing a display: 0
opening a display again: f23010
creating a window again: 5c00001
window id isn't sane enough
destroying a window
closing a display

So window is is re-used in even same program. for more testing, run it some times. you'll get same window id until any applications grabs and keep running.

Comment 20 Matthias Clasen 2008-12-15 15:41:44 UTC
Does my metacity patch solve your problem ? If yes, I'll put it in our Fedora packages.

Comment 21 Fedora Update System 2008-12-15 17:27:27 UTC
metacity-2.24.0-4.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/metacity-2.24.0-4.fc10

Comment 22 Akira TAGOH 2008-12-16 02:56:22 UTC
Unfortunately no. I've installed metacity-2.24.0-4.fc10 and there are still _NET_SUPPORTING_WM_CHECK property in root window before imsettings-xim running say - just put "xprop -root | grep _NET_SUPPORTING_WM_CHECK" line before bringing up imsettings-xim in /etc/X11/xinit/xinitrc.d/50-xinput.sh.

Does this mean metacity shut down with the unexpected way?

Comment 23 Matthias Clasen 2008-12-16 02:59:02 UTC
Yeah, it probably means that metacity was just killed

Comment 24 Matthias Clasen 2008-12-16 03:01:57 UTC
And just to be clear, the basic problem in all of this is that im-settings stuff is started outside the user session.

Comment 25 Akira TAGOH 2008-12-16 03:19:58 UTC
This isn't imsettings specific issue as per comment #8 and comment #12. this issue is still there even if imsettings moves back behind window manager. assuming applications will grabs different window id or _NET_SUPPORTING_WM_CHECK on the root window without window manager running is really bad.

Comment 26 Matthias Clasen 2008-12-16 04:19:18 UTC
Sure, but 

kill wm;...start a bunch of other X apps;... start another wm

is not exactly the typical sequence. 
In most cases, the wm should be the first X app started in the user session. 
Anyway, I'll look at making GTK+ handle this a little better. But not tonight.

Comment 27 Fedora Update System 2008-12-18 00:38:44 UTC
metacity-2.24.0-4.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update metacity'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2008-11381

Comment 28 Heiko Adams 2008-12-26 19:16:17 UTC
Installed metacity-2.24.0-4.fc10 from updates-testing but this does not solve this problem. The problem is still present.

Comment 29 Matthias Clasen 2009-01-04 03:36:42 UTC
Can you try if this build fixes the problem ?

http://koji.fedoraproject.org/koji/taskinfo?taskID=1030934

Comment 30 Kevin Fenzi 2009-01-04 19:38:49 UTC
Yes, the gtk2 package from comment #29 fixes the problem here.

Comment 31 Heiko Adams 2009-01-04 21:21:30 UTC
I can confirm that the gtk2 package from comment #29 fixes the problem

Comment 32 Akira TAGOH 2009-01-05 07:10:56 UTC
I've tried too. it would be better than before. but I can still sometimes see the one-shot error dialog. it's ok next time as what you've fixed.

Comment 33 Ken Dreyer 2009-01-08 15:28:26 UTC
I tried with 

metacity-2.24.0-4.fc10.i386
gtk2-2.14.5-4.fc10.i386

the error only comes up for "Window Manager Tweaks", and only for about the first 60 seconds after logging in to Xfce. After that, the Window Manager Tweaks dialog appears fine.

Comment 34 Ken Dreyer 2009-01-08 15:42:25 UTC
I timed it with "watch -n1 xfce-setting-show wmtweaks"... looks like it's actually only takes about 5 or 10 seconds until it works.

Comment 35 Bug Zapper 2009-11-18 08:53:01 UTC
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 36 Kevin Fenzi 2009-11-18 16:35:33 UTC
This was fixed a while back I am pretty sure... feel free to reopen or file a new one if you spot it again.