GNOME Bugzilla – Bug 139158
gimp-remote complains about $DISPLAY and fails
Last modified: 2004-04-13 16:53:13 UTC
Tried to use gimp-remote-2.0 with the following command 'gimp-remote-2.0 /yada/blat.xcf' but that results in the following message: Xlib: connection to ":0.0" refused by server Xlib: XDM authorization key matches an existing client! GIMP could not initialize the graphical user interface. Make sure a proper setup for your display environment exists. Checked the DISPLAY an it shows ':0.0' Then I tried to start it with 'gimp-remote-2.0 --display=:0.0 /yada/blat.xcf' but I got the same answer. I use the packaged version of Gimp avalible from Debian/unstable
That's an authentication problem with your X-server then. Can you start gimp-2.0 from this console? It will probably fail with the same error message.
Some of our testers are able to reproduce this bug. gimp starts without problems on these machines. There is very old mail discussing the same. http://www.mail-archive.com/lyx-users@lists.lyx.org/msg14443.html
Additional note: When using gdm, which doesn't set XDM-AUTHORIZATION-1, it works fine.
Additional info from SuSE Bugzilla: Additional Comment #21 From Michael Matz 2004-04-07 16:30 I know what happens. gimp-remote-2.0 tries to send the cookie twice. Or better said it sends the cookie, then execve's gimp, and that one also sends the cookie (still same PID!). This happens because the display is opened twice. Now the cookie is uniquified before sending, with time(), and probably PID. _If_ the two cookie sendings happen in the same second the same string will be send and the server correctly notices that this already is there. And because this all is fairly fast (on my machine on 0.09 seconds difference) the two sends only very seldomly happen at different time.
Created attachment 26469 [details] [review] gimp-remote.patch Patch from Michael Matz <matz@suse.de>.
I am afraid this change will break startup notification because of the PID change.
Did some testing and everything seems to run fine. The only way to find out if it works for everyone else is to get the change into 2.0.1. So I have now applied the patch: 2004-04-08 Sven Neumann <sven@gimp.org> * tools/gimp-remote.c (start_new_gimp): applied a patch from Michael Matz that calls fork() before starting gimp. This is to avoid X server authentification problems (bug #139158).
Additional info from SuSE Bugzilla: Additional Comment #30 From Michael Matz 2004-04-08 17:54 Crap. Without a real fix in libX11 (in ConnDis.c:GetAuthorization) to make the unique members more finegraned the only thing left would be to ensure that the gimp executable actually is started after the current second finished. The simplest thing would be to add a sleep(1) . Ugly, but ... Additional Comment #31 From Michael Matz 2004-04-08 17:56 Created an attachment (id=10175) 2. Patch for gimp-remote.c (using sleep) Like in this patch. Also tested locally (i.e. without rebuilding the package)
Created attachment 26479 [details] [review] gimp-remote-sleep.patch
Are you saying the first patch you attached does not work? I have committed it in the meantime.
First patch does work and fixes the problem. But can have problems with startup notification. This new one should not have problems, but adds 1sec delay. I don't know, what is better.
Maybe better idea - don't fork before calling GIMP, but fork before initializing Xlib inside gimp-remote. If this fork will succeed, you have free key for gdk_notify_startup_complete(). If this fork will fail, you have free key for exec GIMP.
I don't like forking at all. Wouldn't it be enough to simply close the display before the exec?
Yosh is right: if it is enough to close the connection to the X server before the exec, that would be a better solution.
Only that there's no GTK+ API to do that. But we can copy _gdk_windowing_exit(). I will come up with such a patch later.
Created attachment 26525 [details] [review] close the X display before calling exec()
I could not reproduce the problem, so I cannot test this. I would appreciate feedback on the patch that I just attached.
Hm, gdk_display_close() would do the job, no?
Yes, of course. No idea why I did not find that. Updated patch will follow.
Created attachment 26533 [details] [review] updated patch using gdk_display_close()
Argh, _gdk_windowing_set_default_display is buggy and causes a crash when used like above. Guess it's best to use Sven's previous patch with XCloseDisplay explictly if that solves this for people.
Created attachment 26534 [details] [review] patch against gimp-2.0.0 using XCloseDisplay()
any objections to me including this patch in the Debian gimp package?
Oh, and Debian bug tracking this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=109344
The patch will be in 2.0.1 which is supposed to be released today to tomorrow.
Even though there hasn't been any positive feedback, there was no negative feedback neither, so I've committed this fix now. We need to get 2.0.1 out: 2004-04-10 Sven Neumann <sven@gimp.org> * tools/gimp-remote.c (start_new_gimp): reverted the last change and did a different fix that involves closing the X display before starting gimp (bug #139158).
It seems, that patch in comment #22 does not help. Authorization key probably cannot be re-used even after explicit XCloseDisplay(). How to repeat the problem: At least XDM and KDM can be switched to use XDM-AUTHENTICATION-1 key. For XDM see /etc/X11/xdm/xdm-config. It seems, that fork() is only work-around. If there can be any check for this bug in configure, fork() code described in comment #12 can be optional.
The xdm/gdm configuration cannot possibly be checked in configure.
I didn't mentioned XDM checking, but checking for ConnDis.c:GetAuthorization XLib bug. I have no idea, how to simply check for it. Maybe simplest is list of X versions with this bug (all version of XFree until now, probably latest Xorg, too). For affected versions make a fork(), for other versions (none yet) do not fork.
We can also hardly check for the X11 version because we cannot know the version of the X11 library GIMP will be run on when the GIMP configure check is done. Theoretically we could check the version at run-time but that doesn't sound feasible. If this is really an X11 bug I tend to say that it should be fixed in X11 then. But since a lot of systems seems affected we should consider to workaround it using fork(). There weren't any good arguments not to use fork(), so if you think there are any, please speak up.
All XFree system are affected, if you use XDM authentization instead of MIT magic cookie. None good arguments against fork(), except startup notification. See comment #12 - it can work (not yet tested).
2004-04-13 Sven Neumann <sven@gimp.org> * tools/gimp-remote.c: reverted last change and go back to the solution using fork(). Hopefully fixes bug #139158 this time.