bug#3399: Crash in multi-TTY mode

bug#3399: Crash in multi-TTY mode

[Shannon Jones]

I'm almost embarrassed to report this, since it's rather strange and
most likely unique to my setup.  Still, it involves a crash so I
thought it would be worthwhile to see if anyone else can reproduce it.

* Emacs version: GNU Emacs 23.0.94.1 (i686-pc-linux-gnu, GTK+ Version
  2.10.4) of 2009-05-26

* Compiled on CentOS 5.3.

* No options given to configure

* To reproduce:

Run screen
In screen, run 'emacs -Q -nw'
M-x server-start
Detach screen (C-a d)

Now emacs is running in the background inside screen.

Run 'emacsclient -c' outside of screen, but as the same user.

As the window is painting, hit C-x C-c

The window will close.  Re-open screen, and see that Emacs has crashed
with this error:

Fatal error (11)Segmentation fault (core dumped)

My emacs is running on a server, and I'm displaying on my home machine
over the internet.  The latency is high enough that I can see the
screen painting (it takes about 5-10 seconds to fully paint the first
time).  If I wait until the window is completely open, then C-x C-c
doesn't crash emacs.

I'm using Windows XP with Xming 6.9.0.31 as the X server.  I can
reproduce it 100% of the time on this machine.

If I use Ubuntu 8.10 as the X server, then emacs doesn't crash.
However, on Ubuntu 8.10, if I hit C-x C-c repeatedly while the window
is drawing, then the background emacs (the one running in screen)
exits but doesn't crash.  It shouldn't exit, since I was typing C-x
C-c in the emacsclient window, not the background emacs session.  I
get 'xcxcxc' repeated on the command prompt in the screen session.  I
presume this is because I was repeatedly typing C-x C-c in the
emacsclient window.  Even though it was detatched, typing in the
emacsclient window is causing letters to appear on the command prompt
in the screen session.


Here is some output from gdb from core dump:
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x420a81b6 in kill () from /lib/libc.so.6
#2  0x0811853f in fatal_error_signal (sig=11) at /home/sjones/src/emacs-23.0.94/src/emacs.c:403
#3  <signal handler called>
#4  0x423b98cb in ?? () from /usr/lib/libX11.so.6
#5  0x423b9951 in XrmDestroyDatabase () from /usr/lib/libX11.so.6
#6  0x080d6662 in x_delete_terminal (terminal=0x8566ff0) at /home/sjones/src/emacs-23.0.94/src/xterm.c:10748
#7  0x080cd0f2 in Fdelete_terminal (terminal=139882484, force=137882961) at /home/sjones/src/emacs-23.0.94/src/terminal.c:331
#8  0x0806296c in delete_frame (frame=141662156, force=137882961) at /home/sjones/src/emacs-23.0.94/src/frame.c:1511
#9  0x0818286e in Ffuncall (nargs=2, args=0xbf85a560) at /home/sjones/src/emacs-23.0.94/src/eval.c:3048
#10 0x081b5632 in Fbyte_code (bytestr=139173083, vector=140402188, maxdepth=48) at /home/sjones/src/emacs-23.0.94/src/bytecode.c:678
#11 0x081822d7 in funcall_lambda (fun=139418028, nargs=1, arg_vector=0xbf85a694) at /home/sjones/src/emacs-23.0.94/src/eval.c:3232
#12 0x081826fb in Ffuncall (nargs=2, args=0xbf85a690) at /home/sjones/src/emacs-23.0.94/src/eval.c:3102
#13 0x081b5632 in Fbyte_code (bytestr=138274787, vector=140375140, maxdepth=32) at /home/sjones/src/emacs-23.0.94/src/bytecode.c:678
#14 0x081822d7 in funcall_lambda (fun=140271524, nargs=1, arg_vector=0xbf85a7b4) at /home/sjones/src/emacs-23.0.94/src/eval.c:3232
#15 0x081826fb in Ffuncall (nargs=2, args=0xbf85a7b0) at /home/sjones/src/emacs-23.0.94/src/eval.c:3102
#16 0x081b5632 in Fbyte_code (bytestr=136489203, vector=136489220, maxdepth=24) at /home/sjones/src/emacs-23.0.94/src/bytecode.c:678
#17 0x081822d7 in funcall_lambda (fun=136489156, nargs=1, arg_vector=0xbf85a924) at /home/sjones/src/emacs-23.0.94/src/eval.c:3232
#18 0x081826fb in Ffuncall (nargs=2, args=0xbf85a920) at /home/sjones/src/emacs-23.0.94/src/eval.c:3102
#19 0x0817fb27 in Fcall_interactively (function=138844913, record_flag=137882913, keys=137921284) at /home/sjones/src/emacs-23.0.94/src/callint.c:868
#20 0x0818288e in Ffuncall (nargs=4, args=0xbf85aad0) at /home/sjones/src/emacs-23.0.94/src/eval.c:3051
#21 0x08182aa9 in call3 (fn=138047481, arg1=138844913, arg2=137882913, arg3=137882913) at /home/sjones/src/emacs-23.0.94/src/eval.c:2875
#22 0x08127dbb in command_loop_1 () at /home/sjones/src/emacs-23.0.94/src/keyboard.c:1901
#23 0x08181262 in internal_condition_case (bfun=0x8127a50 <command_loop_1>, handlers=137926017, hfun=0x81229e0 <cmd_error>) at /home/sjones/src/emacs-23.0.94/src/eval.c:1512
#24 0x08121f73 in command_loop_2 () at /home/sjones/src/emacs-23.0.94/src/keyboard.c:1359
#25 0x0818131a in internal_catch (tag=137922041, func=0x8121f50 <command_loop_2>, arg=137882913) at /home/sjones/src/emacs-23.0.94/src/eval.c:1248
#26 0x08122837 in command_loop () at /home/sjones/src/emacs-23.0.94/src/keyboard.c:1338
#27 0x08122bab in recursive_edit_1 () at /home/sjones/src/emacs-23.0.94/src/keyboard.c:953
#28 0x08122ce1 in Frecursive_edit () at /home/sjones/src/emacs-23.0.94/src/keyboard.c:1015
#29 0x0811785b in main (argc=Cannot access memory at address 0x1
) at /home/sjones/src/emacs-23.0.94/src/emacs.c:1852




(gdb) frame 6
#6  0x080d6662 in x_delete_terminal (terminal=0x8566ff0) at /home/sjones/src/emacs-23.0.94/src/xterm.c:10748
10748         XrmDestroyDatabase (dpyinfo->xrdb);


(gdb) print *dpyinfo
$1 = {next = 0x0, terminal = 0x8566ff0, connection = 6, display = 0x86b99f8, name_list_element = 140648661, reference_count = 0, screen = 0x8625570, resx = 75.027692307692305, resy = 74.950819672131146, visual = 0x85de890, cmap = 32,
  n_planes = 24, grabbed = 0, icon_bitmap_id = -1, root_window = 62, client_leader_window = 0, vertical_scroll_bar_cursor = 8388619, xg_cursor = 0x8534fb8, xrdb = 0x8567158, smallest_char_width = 7, smallest_font_height = 15,
  scratch_cursor_gc = 0x0, mouse_face_beg_row = -1, mouse_face_beg_col = -1, mouse_face_beg_x = 0, mouse_face_beg_y = 0, mouse_face_end_row = -1, mouse_face_end_col = -1, mouse_face_end_x = 0, mouse_face_end_y = 0,
  mouse_face_past_end = 0, mouse_face_window = 137882913, mouse_face_face_id = 0, mouse_face_overlay = 137882913, mouse_face_deferred_gc = 0, mouse_face_mouse_frame = 0x0, mouse_face_mouse_x = 577, mouse_face_mouse_y = 263,
  mouse_face_defer = 0, mouse_face_hidden = 0, mouse_face_image_state = 0, x_id_name = 0x8535020 "emacs@mymachine.example.com", n_fonts = 6, bitmaps = 0x0, bitmaps_size = 0, bitmaps_last = 0, meta_mod_mask = 8, shift_lock_mask = 0,
  alt_mod_mask = 0, super_mod_mask = 0, hyper_mod_mask = 0, Xatom_wm_protocols = 165, Xatom_wm_take_focus = 262, Xatom_wm_save_yourself = 276, Xatom_wm_delete_window = 166, Xatom_wm_change_state = 168, Xatom_wm_configure_denied = 277,
  Xatom_wm_window_moved = 278, Xatom_wm_client_leader = 191, Xatom_editres = 254, Xatom_CLIPBOARD = 169, Xatom_TIMESTAMP = 279, Xatom_TEXT = 280, Xatom_DELETE = 281, Xatom_COMPOUND_TEXT = 173, Xatom_UTF8_STRING = 172,
  Xatom_MULTIPLE = 282, Xatom_INCR = 283, Xatom_EMACS_TMP = 284, Xatom_TARGETS = 174, Xatom_NULL = 285, Xatom_ATOM_PAIR = 286, Xatom_PIXEL_SIZE = 151, Xatom_AVERAGE_WIDTH = 156, Xatom_MULE_BASELINE_OFFSET = 287,
  Xatom_MULE_RELATIVE_COMPOSE = 288, Xatom_MULE_DEFAULT_ASCENT = 289, Xatom_DONE = 291, Xatom_PAGE = 290, Xatom_Scrollbar = 292, Xatom_XEMBED = 293, cut_buffers_initialized = 0, x_focus_frame = 0x0, x_focus_event_frame = 0x0,
  x_highlight_frame = 0x0, gray = 8388620, xim = 0x0, xim_styles = 0x85eeee0, xim_callback_data = 0x85fc2e8, color_cells = 0x0, ncolor_cells = 0, red_bits = 8, blue_bits = 8, green_bits = 8, red_offset = 16, blue_offset = 0,
  green_offset = 8, wm_type = X_WMTYPE_UNKNOWN, x_dnd_atoms = 0x853cfa0, x_dnd_atoms_size = 8, x_dnd_atoms_length = 6, net_supported_atoms = 0x0, nr_net_supported_atoms = 0, net_supported_window = 0, Xatom_net_wm_state = 266,
  Xatom_net_wm_state_fullscreen_atom = 270, Xatom_net_wm_state_maximized_horz = 269, Xatom_net_wm_state_maximized_vert = 268}


(gdb) print dpyinfo->xrdb
$2 = (XrmDatabase) 0x8567158

bug#3399: Crash in multi-TTY mode

[YAMAMOTO Mitsuharu]

>>>>> On 27 May 2009 02:44:23 -0000, "Shannon Jones" <cz2s20d02@sneakemail.com> said:

> I'm almost embarrassed to report this, since it's rather strange and
> most likely unique to my setup.  Still, it involves a crash so I
> thought it would be worthwhile to see if anyone else can reproduce
> it.

I could reproduce it on GTK+/Mac OS X with the following steps.

  $ emacs -nw -Q
  M-x server-start RET
  $ emacsclient -c
  C-x 5 0 (on the X11 frame)

The problematic scenario is:

  1. XGetDefault is called in several GTK+ initialization steps.  It
     sets the XlibDisplayDfltRMDB bit in dpy->flags but dpy->db
     remains to be NULL in some cases (InitDefaults may return NULL).

    GetDflt.c (libX11-1.2.1):

    char *
    XGetDefault(
	    Display *dpy,			/* display for defaults.... */
	    char _Xconst *prog,		/* name of program for option	*/
	    register _Xconst char *name)	/* name of option program wants */
    {					/* to get, for example, "font"  */

	:

	    /*
	     * see if database has ever been initialized.  Lookups can be done
	     * without locks held.
	     */
	    LockDisplay(dpy);
	    if (dpy->db == NULL) {
		dpy->db = InitDefaults(dpy);
		dpy->flags |= XlibDisplayDfltRMDB;
	    }
	    UnlockDisplay(dpy);

	:

    }
  2. x_term_init calls XrmSetDatabase, but it doesn't reset the
     XlibDisplayDfltRMDB bit if display->db is NULL.  As a result,
     display->db holds a new database but XlibDisplayDfltRMDB is still
     set.

    Xrm.c (libX11-1.2.1):

    void XrmSetDatabase(
	Display *display,
	XrmDatabase database)
    {
	LockDisplay(display);
	/* destroy database if set up imlicitely by XGetDefault() */
	if (display->db && (display->flags & XlibDisplayDfltRMDB)) {
	    XrmDestroyDatabase(display->db);
	    display->flags &= ~XlibDisplayDfltRMDB;
	}
	display->db = database;
	UnlockDisplay(display);
    }

  3. x_delete_terminal does XrmSetDatabase(dpyinfo->display, NULL) to
     dissociate the database from the display.  Because
     XlibDisplayDfltRMDB is set, it destroys the database to be
     dissociated.

  4. x_delete_terminal then calls XrmSetDatabase and destroys the
     dissociated database again.  This causes crash.

I think this a bug in libX11.  It should either 1) not set
XlibDisplayDfltRMDB in XGetDefault unless dpy->db becomes non-NULL or
2) reset XlibDisplayDfltRMDB in XrmSetDatabase even if the previous
database is NULL.

Below is a possible workaround.  Unfortunately, we need to touch some
X11 internal data structures.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/xterm.c
===================================================================
RCS file: /sources/emacs/emacs/src/xterm.c,v
retrieving revision 1.1026
diff -c -p -r1.1026 xterm.c
*** src/xterm.c	19 May 2009 00:26:46 -0000	1.1026
--- src/xterm.c	27 May 2009 07:59:20 -0000
*************** along with GNU Emacs.  If not, see <http
*** 31,36 ****
--- 31,40 ----
  
  #ifdef HAVE_X_WINDOWS
  
+ /* This makes the fields of a Display accessible, in Xlib header files.  */
+ 
+ #define XLIB_ILLEGAL_ACCESS
+ 
  #include "lisp.h"
  #include "blockinput.h"
  
*************** x_term_init (display_name, xrm_option, r
*** 10285,10290 ****
--- 10289,10304 ----
  
    xrdb = x_load_resources (dpyinfo->display, xrm_option,
  			   resource_name, EMACS_CLASS);
+   /* This is a workaround for a bug in some versions of libX11.
+      XGetDefault may set XlibDisplayDfltRMDB (1L << 7) in dpy->flags
+      (dpyinfo->display->private16) even when dpy->db
+      (dpyinfo->display->db) remains to be NULL, and XrmSetDatabase
+      doesn't clear the flag if dpy->db is NULL.  This causes crash in
+      the XrmDestroyDatabase call from x_delete_terminal because the
+      preceding XrmSetDatabase call destroys the associated database
+      because of the XlibDisplayDfltRMDB flag.  */
+   if (dpyinfo->display->db == NULL)
+     dpyinfo->display->private16 &= ~(1L << 7);
  #ifdef HAVE_XRMSETDATABASE
    XrmSetDatabase (dpyinfo->display, xrdb);
  #else

bug#3399: Crash in multi-TTY mode

[Stefan Monnier]

>> I'm almost embarrassed to report this, since it's rather strange and
>> most likely unique to my setup.  Still, it involves a crash so I
>> thought it would be worthwhile to see if anyone else can reproduce
>> it.

> The problematic scenario is:
[...]

Thanks for tracking it down.

> I think this a bug in libX11.  It should either 1) not set
> XlibDisplayDfltRMDB in XGetDefault unless dpy->db becomes non-NULL or
> 2) reset XlibDisplayDfltRMDB in XrmSetDatabase even if the previous
> database is NULL.

I'm not sure I understand all the details, but I really find the
workaround hideous (tho I do think you for coming up with it): what if
we undo your recent change that does XrmSetDatabase(dpyinfo->display,
NULL) and just free the xrm database (i.e. introducing a double-free
crash in older libX11)?  Would this also work around this problem?


        Stefan

bug#3399: Crash in multi-TTY mode

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 27 May 2009 10:31:20 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> I think this a bug in libX11.  It should either 1) not set
>> XlibDisplayDfltRMDB in XGetDefault unless dpy->db becomes non-NULL
>> or 2) reset XlibDisplayDfltRMDB in XrmSetDatabase even if the
>> previous database is NULL.

> I'm not sure I understand all the details, but I really find the
> workaround hideous (tho I do think you for coming up with it): what
> if we undo your recent change that does
> XrmSetDatabase(dpyinfo->display, NULL) and just free the xrm
> database (i.e. introducing a double-free crash in older libX11)?
> Would this also work around this problem?

[To simplify the argument, I restrict myself to the GTK+ case below.
 My recent change includes a fix for the crash in the no-toolkit version.]

The situation is classified into the three cases:

  1. Older libX11 that doesn't care about XlibDisplayDfltRMDB at all.
  2. Newer libX11, when the first XGetDefault call sets dpy->db to a
     non-NULL value.
  3. Newer libX11, when the first XGetDefault call sets dpy->db to NULL.

Case 3 corresponds to the problematic scenario I mentioned in my
previous mail and the other cases should work fine currently.  Undoing
my recent change means that we don't destroy the database ourselves,
and it leaks memory in Case 2 and 3.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#3399: Crash in multi-TTY mode

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 28 May 2009 09:47:32 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> The situation is classified into the three cases:

>   1. Older libX11 that doesn't care about XlibDisplayDfltRMDB at all.
>   2. Newer libX11, when the first XGetDefault call sets dpy->db to a
>      non-NULL value.
>   3. Newer libX11, when the first XGetDefault call sets dpy->db to NULL.

> Case 3 corresponds to the problematic scenario I mentioned in my
> previous mail and the other cases should work fine currently.  Undoing
> my recent change means that we don't destroy the database ourselves,
> and it leaks memory in Case 2 and 3.

Correction: undoing my recent change causes memory leaks in Case 2.

Also, I filed a bug report about XrmSetDatabase into the freedesktop
bugzilla (http://bugs.freedesktop.org/show_bug.cgi?id=21974).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#3399: Crash in multi-TTY mode

[Stefan Monnier]

>   1. Older libX11 that doesn't care about XlibDisplayDfltRMDB at all.
>   2. Newer libX11, when the first XGetDefault call sets dpy->db to a
>      non-NULL value.
>   3. Newer libX11, when the first XGetDefault call sets dpy->db to NULL.

> Case 3 corresponds to the problematic scenario I mentioned in my
> previous mail and the other cases should work fine currently.  Undoing
> my recent change means that we don't destroy the database ourselves,
> and it leaks memory in Case 2 and 3.

What if (as asked) we don't just undo your change, but additionally
return to freeing the DB (so we'll get a crash in case 1)?  Will we then
also get a crash in case 2 or 3?


        Stefan

bug#3399: Crash in multi-TTY mode

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 28 May 2009 09:14:06 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> 1. Older libX11 that doesn't care about XlibDisplayDfltRMDB at all.
>> 2. Newer libX11, when the first XGetDefault call sets dpy->db to a
>> non-NULL value.
>> 3. Newer libX11, when the first XGetDefault call sets dpy->db to NULL.

>> Case 3 corresponds to the problematic scenario I mentioned in my
>> previous mail and the other cases should work fine currently.  Undoing
>> my recent change means that we don't destroy the database ourselves,
>> and it leaks memory in Case 2 and 3.

As I corrected, the memory leak happens only in Case 2, which is the
most common case I guess.

> What if (as asked) we don't just undo your change, but additionally
> return to freeing the DB (so we'll get a crash in case 1)?  Will we then
> also get a crash in case 2 or 3?

It will crash in Case 3 as well as 1.  XCloseDisplay destroys the
associated database because XlibDisplayDfltRMDB is set, although the
database was not actually what's allocated by some XGetDefault call.
That's why I consider this is a bug in libX11.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#3399: Crash in multi-TTY mode

[Stefan Monnier]

>> What if (as asked) we don't just undo your change, but additionally
>> return to freeing the DB (so we'll get a crash in case 1)?  Will we then
>> also get a crash in case 2 or 3?

> It will crash in Case 3 as well as 1.  XCloseDisplay destroys the
> associated database because XlibDisplayDfltRMDB is set, although the
> database was not actually what's allocated by some XGetDefault call.
> That's why I consider this is a bug in libX11.

Thanks, so yes, that sounds like a plain bug in libX11.

Now I'm not sure if I prefer the crash or the hideous workaround.
At the very least, the hideous workaround should be wrapped in
"#ifdef HIDEOUS_WORKAROUND" (or some more descriptive name).  Ideally,
we could then use an autoconf macro to only activate the workaround when
needed.


        Stefan

bug#3399: Crash in multi-TTY mode

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 29 May 2009 10:30:09 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> Now I'm not sure if I prefer the crash or the hideous workaround.
> At the very least, the hideous workaround should be wrapped in
> "#ifdef HIDEOUS_WORKAROUND" (or some more descriptive name).
> Ideally, we could then use an autoconf macro to only activate the
> workaround when needed.

But in general it's impossible to tell at configure time which
version of libX11 will be linked at runtime.

I'd prefer the conservative "maybe leaking" one at this stage as I
said first in
http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00263.html .

The third non-crashing non-hideous way would be to associate the
created database before any call to XGetDefault so it may not set the
XlibDisplayDfltRMDB flag.  That will require reordering in the display
initialization and we can try it after the release.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#3399: Crash in multi-TTY mode

[Stefan Monnier]

> I'd prefer the conservative "maybe leaking" one at this stage as I
> said first in
> http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00263.html.

The main problem with this is that the "maybe" is "in 99% of the cases",
since only ancient versions of libX11 free the database.

> The third non-crashing non-hideous way would be to associate the
> created database before any call to XGetDefault so it may not set the
> XlibDisplayDfltRMDB flag.  That will require reordering in the display
> initialization and we can try it after the release.

BTW, is there any hope that the bug in libX11 will be fixed any
time soon (not that it will save us, but at least I'd like to make sure
that we're not stuck with such painful workarounds indefinitely).


        Stefan

bug#3399: Crash in multi-TTY mode

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 30 May 2009 16:37:02 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> I'd prefer the conservative "maybe leaking" one at this stage as I
>> said first in
>> http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00263.html.

> The main problem with this is that the "maybe" is "in 99% of the
> cases", since only ancient versions of libX11 free the database.

But even with the newer libX11, we can't avoid both memory leaks (Case
2) and crash (Case 3) without a "hideous" workaround or a nontrivial
change in the display initialization.  Also, the situation before my
recent change was also "maybe leaking" for GTK+.  I think this is
acceptable enough for Emacs 23.1.

>> The third non-crashing non-hideous way would be to associate the
>> created database before any call to XGetDefault so it may not set
>> the XlibDisplayDfltRMDB flag.  That will require reordering in the
>> display initialization and we can try it after the release.

> BTW, is there any hope that the bug in libX11 will be fixed any time
> soon (not that it will save us, but at least I'd like to make sure
> that we're not stuck with such painful workarounds indefinitely).

There's no response so far, and I'm not sure how bug reports are
usually dealt with in X.org.  Actually, I created my bugzilla account
in freedesktop.org for this bug.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

bug#3399: Crash in multi-TTY mode

[Stefan Monnier]

>>> I'd prefer the conservative "maybe leaking" one at this stage as I
>>> said first in
>>> http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00263.html.

>> The main problem with this is that the "maybe" is "in 99% of the
>> cases", since only ancient versions of libX11 free the database.

> But even with the newer libX11, we can't avoid both memory leaks (Case
> 2) and crash (Case 3) without a "hideous" workaround or a nontrivial
> change in the display initialization.  Also, the situation before my
> recent change was also "maybe leaking" for GTK+.  I think this is
> acceptable enough for Emacs 23.1.

Yes, maybe the leak is the least-bad of the options we have, as you said.

>>> The third non-crashing non-hideous way would be to associate the
>>> created database before any call to XGetDefault so it may not set
>>> the XlibDisplayDfltRMDB flag.  That will require reordering in the
>>> display initialization and we can try it after the release.

>> BTW, is there any hope that the bug in libX11 will be fixed any time
>> soon (not that it will save us, but at least I'd like to make sure
>> that we're not stuck with such painful workarounds indefinitely).

> There's no response so far, and I'm not sure how bug reports are
> usually dealt with in X.org.  Actually, I created my bugzilla account
> in freedesktop.org for this bug.

OK, thanks for reporting it,


        Stefan