Bug reported on the Debian BTS today by Sjoerd Simons. If I start Xephyr 1.3.0 with a xterm, closing this xterm causes Xephyr to crash with the following backtrace: Program received signal SIGSEGV, Segmentation fault. __glXMesaScreenDestroy (screen=0x84251e8) at ../../../../GL/mesa/X/xf86glx.c:285 285 if (mesaScreen->xm_vis[i]) (gdb) bt full #0 __glXMesaScreenDestroy (screen=0x84251e8) at ../../../../GL/mesa/X/xf86glx.c:285 i = 0 #1 0x08125f54 in __glXResetScreens () at ../../../GL/glx/glxscreens.c:358 i = 0 #2 0x081250dc in ResetExtension (extEntry=0x84259f0) at ../../../GL/glx/glxext.c:75 No locals. #3 0x08075ad2 in CloseDownExtensions () at ../../dix/extension.c:293 i = 21 j = 0 #4 0x08079ac3 in main (argc=4, argv=0xbfe06c94, envp=Cannot access memory at address 0x9 ) at ../../dix/main.c:483 pScreen = <value optimized out> i = <value optimized out> error = 134714934 xauthfile = <value optimized out> alwaysCheckForInput = {0, 1} Brice
Following Debian bug, a patch was pointed: http://cvs.fedora.redhat.com/viewcvs/*checkout*/rpms/xorg-x11-server/devel/xserver-1.2.99.901-xephyr-crash-at-exit.patch?rev=1.1 I applied it and now xephyr works as expected.
Hello, The problem seems to persist in the xephyr of the master branch. I have tracked it a little bit, so I will try to describe what I saw a little bit so that I do not forget myself. When the last client disconnects from the server, the server resets. It means the server "restarts", basically. The while loop in dix/main.c does a new iteration. Resources get freed and the initialisation sequence of the server gets redone again. During this reset, the server then exits because the call to SetDefaultFont(defaultTextFont) (in main(), in dix/main.c fails). SetDefaultFont() fails because the font named "fixed" (this is an alias) is not found in the font path named "built-ins". The "fixed" font is found the first time the server is booted, though, but not the second time, when it resets. I tracked this down to the libxfont library. The explanation seems to be a bit awkward and I am sorry for that, but the code path is not very simple either. In main(), before SetDefaultFont(), there is a SetDefaultFontPath() that sets the font search path to "built-ins" directory. That function also loads a set of predefined fonts. To load those fonts, it calls (indirectly via SetFontPathElements()) the function BuiltinReadDirectory(), from libxfont. The names of the fonts to load are hardcoded in global variable named builtin_dir, in src/builtin/fonts.c, in libXfonts. The problem is, in BuiltinReadDirectory(), the function that loads the font (FontFileAddFontFile()) changes the font name ! Yes, it changes the global name of the font, stored in the global variable builtin_dir. That is an annoying side effect. But the font look algorithms rely on this name changing side effect especially to scalable font name resolution. So This side effect must be kept, otherwise some non trivial parts of libxfont must be re-written. So, the next time the function BuiltinReadDirectory() is called, a different font name is loaded. This means when the server is reset, a different font name is pre loaded by SetDefaultFontPath(). SetDefault(), called in main() after SetDefaultFontPath() does not find the font named "fixed" because SetDefaultFontPath() did not properly load the matching font, due to the side effect. I will try to attach a patch illustrate and hopefully fixes the problem.
Okay, I opened bug #11619 against libxfont and attached patch #10748 to try to solve the problem. This patch solves the problem for me.
This bug should be fixed by the resolution of bug #11619
I guess commit c09e68ce30dabd6b7068b163b9d2382d85d0d0bc in Xserver has a lot to do with this being fixed too (this is the patch from comment #1).
Yeah, sure. But it was not enough. There were actually multiple problems stacked up here, as all the comments suggest.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.