bug#581: 23.0.60; OSX: server crashes when quitting emacsclient

bug#581: 23.0.60; OSX: server crashes when quitting emacsclient

[Markus Triska]

When I do:

     $ emacs -Q -nw -f server-start

and in another terminal:

     $ emacsclient -c

and then quit the client with C-x C-c, the server crashes with the
following backtrace. When I omit "-nw" for the server, it works.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0fd07d39
0x018167ad in DestroyNTable ()
(gdb) bt
#0  0x018167ad in DestroyNTable ()
#1  0x01816873 in XrmDestroyDatabase ()
#2  0x00095fb0 in x_delete_display (dpyinfo=0x214c040) at xterm.c:10523
#3  0x00096107 in x_delete_terminal (terminal=0x214c1f0) at xterm.c:10654
#4  0x00080081 in Fdelete_terminal (terminal=34914804, force=58721337) at terminal.c:336
#5  0x00011ee8 in Fdelete_frame (frame=34971156, force=58721337) at frame.c:1529
#6  0x0014544c in Ffuncall (nargs=2, args=0xbfffee80) at eval.c:3052
#7  0x0017e99b in Fbyte_code (bytestr=77604907, vector=34753444, maxdepth=6) at bytecode.c:678
#8  0x00144d2f in funcall_lambda (fun=34753700, nargs=1, arg_vector=0xbffff014) at eval.c:3229
#9  0x00145212 in Ffuncall (nargs=2, args=0xbffff010) at eval.c:3099
#10 0x0017e99b in Fbyte_code (bytestr=66970363, vector=34764708, maxdepth=3) at bytecode.c:678
#11 0x00144d2f in funcall_lambda (fun=34764852, nargs=2, arg_vector=0xbffff194) at eval.c:3229
#12 0x00145212 in Ffuncall (nargs=3, args=0xbffff190) at eval.c:3099
#13 0x0017e99b in Fbyte_code (bytestr=2019283, vector=2019300, maxdepth=4) at bytecode.c:678
#14 0x00144d2f in funcall_lambda (fun=2019236, nargs=1, arg_vector=0xbffff364) at eval.c:3229
#15 0x00145212 in Ffuncall (nargs=2, args=0xbffff360) at eval.c:3099
#16 0x001418f2 in Fcall_interactively (function=67043129, record_flag=58721289, keys=51388540) at callint.c:857
#17 0x00145425 in Ffuncall (nargs=4, args=0xbffff560) at eval.c:3048
#18 0x001455c1 in call3 (fn=58833441, arg1=67043129, arg2=58721289, arg3=58721289) at eval.c:2872
#19 0x000e446d in command_loop_1 () at keyboard.c:1912
#20 0x001435a4 in internal_condition_case (bfun=0xe400e <command_loop_1>, handlers=58760953, hfun=0xdce69 <cmd_error>) at eval.c:1511
#21 0x000d6050 in command_loop_2 () at keyboard.c:1369
#22 0x001431f6 in internal_catch (tag=58757025, func=0xd600c <command_loop_2>, arg=58721289) at eval.c:1247
#23 0x000d5df2 in command_loop () at keyboard.c:1348
#24 0x000d5eab in recursive_edit_1 () at keyboard.c:957
#25 0x000d5ff3 in Frecursive_edit () at keyboard.c:1019
#26 0x000d5031 in main (argc=5, argv=0xbffff9d8) at emacs.c:1796

Lisp Backtrace:
"delete-frame" (0xbfffee84)
"server-delete-client" (0xbffff014)
"server-save-buffers-kill-terminal" (0xbffff194)
"save-buffers-kill-terminal" (0xbffff364)
"call-interactively" (0xbffff564)
(gdb) bt full
#0  0x01816746 in DestroyLTable ()
No symbol table info available.
#1  0x0181686c in XrmDestroyDatabase ()
No symbol table info available.
#2  0x00095fb0 in x_delete_display (dpyinfo=0x21447c0) at xterm.c:10523
	t = (struct terminal *) 0x329d50
	dpyinfo = (struct x_display_info *) 0x21447c0
#3  0x00096107 in x_delete_terminal (terminal=0x2144970) at xterm.c:10654
	dpyinfo = (struct x_display_info *) 0x21447c0
	terminal = (struct terminal *) 0x83
#4  0x00080081 in Fdelete_terminal (terminal=34883956, force=58721337) at terminal.c:336
	t = (struct terminal *) 0x2144970
	terminal = 34883956
#5  0x00011ee8 in Fdelete_frame (frame=34944756, force=58721337) at frame.c:1529
	tmp = -1099628544
	f = (struct frame *) 0x21536f0
	sf = (struct frame *) 0x3800439
	kb = (struct kboard *) 0x100
#6  0x0014544c in Ffuncall (nargs=2, args=0xbfffe5c0) at eval.c:3052
	fun = -1073748672
	original_fun = 1803152
	funcar = -1099628544
	numargs = 1
	val = 3306160
	backtrace = {
  next = 0xbfffe70c, 
  function = 0xbfffe5c0, 
  args = 0xbfffe5c4, 
  nargs = 1, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0xbfffe540
	i = -1099628544
	args = (Lisp_Object *) 0x1b8390
#7  0x0017e99b in Fbyte_code (bytestr=77637499, vector=34678884, maxdepth=6) at bytecode.c:678
	op = 131
	vectorp = (Lisp_Object *) 0x2112868
	stack = {
  pc = 0x58f3344 "\210\016$A\211\026$\204o", 
  top = 0xbfffe5c4, 
  bottom = 0xbfffe5c0, 
  byte_string = 77637499, 
  byte_string_start = 0x58f32b4 "\306\307\b\205\a", 
  constants = 34678884, 
  next = 0xbfffe7c4
}
	result = 3306160
	bytestr = -1099628544
#8  0x00144d2f in funcall_lambda (fun=34627908, nargs=1, arg_vector=0xbfffe754) at eval.c:3229
	val = 131
	syms_left = 34627904
	next = 34627904
	i = 1
	optional = 1
	rest = 0
#9  0x00145212 in Ffuncall (nargs=2, args=0xbfffe750) at eval.c:3099
	fun = 34627908
	original_fun = 93438921
	funcar = -1099628544
	numargs = 1
	val = 3306160
	backtrace = {
  next = 0xbfffe88c, 
  function = 0xbfffe750, 
  args = 0xbfffe754, 
  nargs = 1, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0x2106144
	i = -1099628544
	args = (Lisp_Object *) 0x591c3c9
#10 0x0017e99b in Fbyte_code (bytestr=75536379, vector=34704900, maxdepth=3) at bytecode.c:678
	op = 131
	vectorp = (Lisp_Object *) 0x2118e08
	stack = {
  pc = 0x5906043 ")\207", 
  top = 0xbfffe754, 
  bottom = 0xbfffe750, 
  byte_string = 75536379, 
  byte_string_start = 0x5906028 "\303\b!\205\034", 
  constants = 34704900, 
  next = 0xbfffe944
}
	result = 3306160
	bytestr = -1099628544
#11 0x00144d2f in funcall_lambda (fun=34705044, nargs=2, arg_vector=0xbfffe8d4) at eval.c:3229
	val = 131
	syms_left = 34705040
	next = 34705040
	i = 2
	optional = 1
	rest = 0
#12 0x00145212 in Ffuncall (nargs=3, args=0xbfffe8d0) at eval.c:3099
	fun = 34705044
	original_fun = 67043153
	funcar = -1099628544
	numargs = 2
	val = 3306160
	backtrace = {
  next = 0xbfffea0c, 
  function = 0xbfffe8d0, 
  args = 0xbfffe8d4, 
  nargs = 2, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0x2118e94
	i = -1099628544
	args = (Lisp_Object *) 0x3feff51
#13 0x0017e99b in Fbyte_code (bytestr=2019283, vector=2019300, maxdepth=4) at bytecode.c:678
	op = 131
	vectorp = (Lisp_Object *) 0x1ecfe8
	stack = {
  pc = 0x2cc418 "*\207", 
  top = 0xbfffe8d8, 
  bottom = 0xbfffe8d0, 
  byte_string = 2019283, 
  byte_string_start = 0x2cc402 "\303\304 \305\"\304 \030\211\031\204\022", 
  constants = 2019300, 
  next = 0x0
}
	result = 3306160
	bytestr = -1099628544
#14 0x00144d2f in funcall_lambda (fun=2019236, nargs=1, arg_vector=0xbfffeaa4) at eval.c:3229
	val = 131
	syms_left = 2019232
	next = 2019232
	i = 1
	optional = 1
	rest = 0
#15 0x00145212 in Ffuncall (nargs=2, args=0xbfffeaa0) at eval.c:3099
	fun = 2019236
	original_fun = 67043129
	funcar = -1099628544
	numargs = 1
	val = 3306160
	backtrace = {
  next = 0xbfffec4c, 
  function = 0xbfffeaa0, 
  args = 0xbfffeaa4, 
  nargs = 1, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0x1ecfa4
	i = -1099628544
	args = (Lisp_Object *) 0x3feff39
#16 0x001418f2 in Fcall_interactively (function=67043129, record_flag=58721289, keys=51388540) at callint.c:857
	val = 131
	specs = 58750537
	filter_specs = 2019339
	teml = 77516529
	up_event = 58721289
	enable = 58721289
	next_event = 2
	prefix_arg = 58721289
	string = (unsigned char *) 0x2 <Address 0x2 out of bounds>
	tem = (unsigned char *) 0xbe750000 <Address 0xbe750000 out of bounds>
	i = 3306160
	j = 1
	foo = 2
	prompt1 = '\0' <repeats 99 times>
	arg_from_tty = 0
	key_count = 2
	record_then_fail = 0
	save_this_command = 67043129
	save_last_command = 77516529
	save_this_original_command = 67043129
	save_real_this_command = 67043129
#17 0x00145425 in Ffuncall (nargs=4, args=0xbfffeca0) at eval.c:3048
	fun = -1073746780
	original_fun = 58833441
	funcar = -1099628544
	numargs = 3
	val = 3306160
	backtrace = {
  next = 0x0, 
  function = 0xbfffeca0, 
  args = 0xbfffeca4, 
  nargs = 3, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0xbfffeca4
	i = -1099628544
	args = (Lisp_Object *) 0x381ba21
#18 0x001455c1 in call3 (fn=58833441, arg1=67043129, arg2=58721289, arg3=58721289) at eval.c:2872
	ret_ungc_val = 131
#19 0x000e446d in command_loop_1 () at keyboard.c:1912
	cmd = 2
	lose = 2
	nonundocount = 0
	keybuf = {192, 24, -1073746360, 2922218, 0, -1073746832, 2050659, 3298672, 58721289, 51396124, 0, 0, 0, 1330293, 2050600, 2050604, -1073746568, 1330494, 16, 58721289, 7, 0, 1, 0, -1073746596, -1073746784, 0, 0, 58721289, 67054001}
	i = 2
	prev_modiff = 15
	prev_buffer = (struct buffer *) 0x3101678
	already_adjusted = 0
#20 0x001435a4 in internal_condition_case (bfun=0xe400e <command_loop_1>, handlers=58760953, hfun=0xdce69 <cmd_error>) at eval.c:1511
	val = -1099628544
	c = {
  tag = 58721289, 
  val = 58721289, 
  next = 0xbfffee9c, 
  gcpro = 0x0, 
  jmp = {2032511, 1325783, 8096, 1324211, 58721289, 58721289, 3311984, 3298672, -1073746376, -1073746560, 31, 658, 1324360, 1507351, 3276831, 3276831, -1073807360, -1073807305}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 1, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
	h = {
  handler = 58760953, 
  var = 58721289, 
  chosen_clause = 0, 
  tag = 0xbfffed98, 
  next = 0x0
}
#21 0x000d6050 in command_loop_2 () at keyboard.c:1369
	val = 131
#22 0x001431f6 in internal_catch (tag=58757025, func=0xd600c <command_loop_2>, arg=58721289) at eval.c:1247
	c = {
  tag = 58757025, 
  val = 58721289, 
  next = 0x0, 
  gcpro = 0x0, 
  jmp = {895, 0, 8096, 1323354, 5, 0, 3320944, 3298672, -1073746152, -1073746304, 58851359, 658, 1323497, 58851351, 58851359, 58720287, 51380224, 55}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 1, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
	tag = 131
#23 0x000d5df2 in command_loop () at keyboard.c:1348
	val = 131
#24 0x000d5eab in recursive_edit_1 () at keyboard.c:957
	val = 0
#25 0x000d5ff3 in Frecursive_edit () at keyboard.c:1019
	buffer = 58721289
#26 0x000d5031 in main (argc=5, argv=0xbffff11c) at emacs.c:1796
	dummy = -1881117246
	stack_bottom_variable = 0 '\0'
	do_initial_setlocale = 1
	skip_args = 1
	rlim = {
  rlim_cur = 8388608, 
  rlim_max = 67108864
}
	no_loadup = 0
	junk = 0x0

Lisp Backtrace:
"delete-frame" (0xbfffe5c4)
"server-delete-client" (0xbfffe754)
"server-save-buffers-kill-terminal" (0xbfffe8d4)
"save-buffers-kill-terminal" (0xbfffeaa4)
"call-interactively" (0xbfffeca4)


In GNU Emacs 23.0.60.13 (i386-apple-darwin8.11.1, GTK+ Version 2.12.9)
 of 2008-07-20 on mt-computer.local
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

bug#581: Acknowledgement (23.0.60; OSX: server crashes when quitting emacsclient)

[Markus Triska]

I cannot reproduce the problem after commenting out XrmDestroyDatabase:

diff --git a/src/xterm.c b/src/xterm.c
index a32f4e1..884f5a8 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -10516,7 +10516,7 @@ x_delete_display (dpyinfo)
 
 #ifndef USE_X_TOOLKIT   /* I'm told Xt does this itself.  */
 #ifndef AIX		/* On AIX, XCloseDisplay calls this.  */
-  XrmDestroyDatabase (dpyinfo->xrdb);
+  /* XrmDestroyDatabase (dpyinfo->xrdb); */
 #endif
 #endif
 #ifdef HAVE_X_I18N

bug#581: Acknowledgement (23.0.60; OSX: server crashes when quitting emacsclient)

[ＯＦＦＩＣＥ ZERO]

配信不要
----- Original Message ----- 
From: "Markus Triska" <markus.triska@gmx.at>
To: <581@emacsbugs.donarmstrong.com>
Sent: Friday, August 08, 2008 9:08 PM
Subject: bug#581: Acknowledgement (23.0.60;OSX: server crashes when quitting 
emacsclient)


>
> I cannot reproduce the problem after commenting out XrmDestroyDatabase:
>
> diff --git a/src/xterm.c b/src/xterm.c
> index a32f4e1..884f5a8 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -10516,7 +10516,7 @@ x_delete_display (dpyinfo)
>
> #ifndef USE_X_TOOLKIT   /* I'm told Xt does this itself.  */
> #ifndef AIX /* On AIX, XCloseDisplay calls this.  */
> -  XrmDestroyDatabase (dpyinfo->xrdb);
> +  /* XrmDestroyDatabase (dpyinfo->xrdb); */
> #endif
> #endif
> #ifdef HAVE_X_I18N
>
>
>
>
> 

bug#581: Acknowledgement (23.0.60; OSX: server crashes when quitting emacsclient)

[ＯＦＦＩＣＥ ZERO]

Do'nt   send  me mail  !!!
no tkank you!!

----- Original Message ----- 
From: "Markus Triska" <markus.triska@gmx.at>
To: <581@emacsbugs.donarmstrong.com>
Sent: Friday, August 08, 2008 9:08 PM
Subject: bug#581: Acknowledgement (23.0.60;OSX: server crashes when quitting 
emacsclient)


>
> I cannot reproduce the problem after commenting out XrmDestroyDatabase:
>
> diff --git a/src/xterm.c b/src/xterm.c
> index a32f4e1..884f5a8 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -10516,7 +10516,7 @@ x_delete_display (dpyinfo)
>
> #ifndef USE_X_TOOLKIT   /* I'm told Xt does this itself.  */
> #ifndef AIX /* On AIX, XCloseDisplay calls this.  */
> -  XrmDestroyDatabase (dpyinfo->xrdb);
> +  /* XrmDestroyDatabase (dpyinfo->xrdb); */
> #endif
> #endif
> #ifdef HAVE_X_I18N
>
>
>
>
> 

[PATCH] XCloseDisplay already calls XrmDestroyDatabase

[İsmail Dönmez]

[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]

Hi,

Running on Ubuntu's upcoming Intrepid release I experienced X crashes
when I quit emacsclient. The gdb log shows XrmDestroyDatabase() is the
failing line. Looking at

src/xterm.c lines around about 10514:

#ifndef USE_X_TOOLKIT   /* I'm told Xt does this itself.  */
#ifndef AIX            /* On AIX, XCloseDisplay calls this.  */
  XrmDestroyDatabase (dpyinfo->xrdb);
#endif
#endif

So this code assumes only on AIX XCloseDisplay itself calls
XrmDestroyDatabase but this doesn't seem to be the case, looking at
libX11 1.1.4 source code,

src/OpenDis.c starting line 832:

    822     /* if RM database was allocated by XGetDefault() free it */
    823     if (dpy->db && (dpy->flags & XlibDisplayDfltRMDB))
    824         XrmDestroyDatabase(dpy->db);

this is from the _XFreeDisplayStructure() function and the function
documentation says:


 /* XFreeDisplayStructure frees all the storage associated with a
  * Display.  It is used by XOpenDisplay if it runs out of memory,
  * and also by XCloseDisplay.
....
*/

So looks like there is no need to manually call XrmDestroyDatabase()
anymore, attached patch removes it.

Regards,
ismail

-- 
Programmer Excuse #4: It's too complicated for you to understand.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xrm.patch --]
[-- Type: text/x-diff; name=xrm.patch, Size: 444 bytes --]

diff --git a/src/xterm.c b/src/xterm.c
index a32f4e1..b5b3f19 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -10514,11 +10514,6 @@ x_delete_display (dpyinfo)
 	  tail->next = tail->next->next;
     }
 
-#ifndef USE_X_TOOLKIT   /* I'm told Xt does this itself.  */
-#ifndef AIX		/* On AIX, XCloseDisplay calls this.  */
-  XrmDestroyDatabase (dpyinfo->xrdb);
-#endif
-#endif
 #ifdef HAVE_X_I18N
   if (dpyinfo->xim)
     xim_close_dpy (dpyinfo);

Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase

[İsmail Dönmez]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

Hi again,

On Tue, Aug 19, 2008 at 13:19, İsmail Dönmez <ismail@namtrac.org> wrote:
> Hi,
>
> Running on Ubuntu's upcoming Intrepid release I experienced X crashes
> when I quit emacsclient. The gdb log shows XrmDestroyDatabase() is the
> failing line. Looking at
>
> src/xterm.c lines around about 10514:
>
> #ifndef USE_X_TOOLKIT   /* I'm told Xt does this itself.  */
> #ifndef AIX            /* On AIX, XCloseDisplay calls this.  */
>  XrmDestroyDatabase (dpyinfo->xrdb);
> #endif
> #endif
>
> So this code assumes only on AIX XCloseDisplay itself calls
> XrmDestroyDatabase but this doesn't seem to be the case, looking at
> libX11 1.1.4 source code,
>
> src/OpenDis.c starting line 832:
>
>    822     /* if RM database was allocated by XGetDefault() free it */
>    823     if (dpy->db && (dpy->flags & XlibDisplayDfltRMDB))
>    824         XrmDestroyDatabase(dpy->db);
>
> this is from the _XFreeDisplayStructure() function and the function
> documentation says:
>
>
>  /* XFreeDisplayStructure frees all the storage associated with a
>  * Display.  It is used by XOpenDisplay if it runs out of memory,
>  * and also by XCloseDisplay.
> ....
> */
>
> So looks like there is no need to manually call XrmDestroyDatabase()
> anymore, attached patch removes it.

Actually correct solution is to disable XrmDestroyDatabase() call for
GTK+ as done for Xt. See attached patch.

Regards,
ismail

-- 
Programmer Excuse #4: It's too complicated for you to understand.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xrm2.patch --]
[-- Type: text/x-diff; name=xrm2.patch, Size: 455 bytes --]

diff --git a/src/xterm.c b/src/xterm.c
index a32f4e1..9b9b976 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -10514,7 +10514,7 @@ x_delete_display (dpyinfo)
 	  tail->next = tail->next->next;
     }
 
-#ifndef USE_X_TOOLKIT   /* I'm told Xt does this itself.  */
+#if ! defined (USE_X_TOOLKIT) && ! defined (USE_GTK) /* Xt and GTK does this by itself */
 #ifndef AIX		/* On AIX, XCloseDisplay calls this.  */
   XrmDestroyDatabase (dpyinfo->xrdb);
 #endif

Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase

[İsmail Dönmez]

Hi,

On Wed, Aug 20, 2008 at 11:17, İsmail Dönmez <ismail@namtrac.org> wrote:
> Hi again,
>
> On Tue, Aug 19, 2008 at 13:19, İsmail Dönmez <ismail@namtrac.org> wrote:
>> Hi,
>>
>> Running on Ubuntu's upcoming Intrepid release I experienced X crashes
>> when I quit emacsclient. The gdb log shows XrmDestroyDatabase() is the
>> failing line. Looking at
>>
>> src/xterm.c lines around about 10514:
>>
>> #ifndef USE_X_TOOLKIT   /* I'm told Xt does this itself.  */
>> #ifndef AIX            /* On AIX, XCloseDisplay calls this.  */
>>  XrmDestroyDatabase (dpyinfo->xrdb);
>> #endif
>> #endif
>>
>> So this code assumes only on AIX XCloseDisplay itself calls
>> XrmDestroyDatabase but this doesn't seem to be the case, looking at
>> libX11 1.1.4 source code,
>>
>> src/OpenDis.c starting line 832:
>>
>>    822     /* if RM database was allocated by XGetDefault() free it */
>>    823     if (dpy->db && (dpy->flags & XlibDisplayDfltRMDB))
>>    824         XrmDestroyDatabase(dpy->db);
>>
>> this is from the _XFreeDisplayStructure() function and the function
>> documentation says:
>>
>>
>>  /* XFreeDisplayStructure frees all the storage associated with a
>>  * Display.  It is used by XOpenDisplay if it runs out of memory,
>>  * and also by XCloseDisplay.
>> ....
>> */
>>
>> So looks like there is no need to manually call XrmDestroyDatabase()
>> anymore, attached patch removes it.
>
> Actually correct solution is to disable XrmDestroyDatabase() call for
> GTK+ as done for Xt. See attached patch.

Any comments on this? It fixes a frequent crash for me.

Regards,
ismail

-- 
Programmer Excuse #4: It's too complicated for you to understand.

Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase

[Chong Yidong]

"İsmail Dönmez" <ismail@namtrac.org> writes:

>>> So looks like there is no need to manually call XrmDestroyDatabase()
>>> anymore, attached patch removes it.
>>
>> Actually correct solution is to disable XrmDestroyDatabase() call for
>> GTK+ as done for Xt. See attached patch.
>
> Any comments on this? It fixes a frequent crash for me.

I've checked in the patch.  Thanks.

bug#581: marked as done (23.0.60; OSX: server crashes when quitting emacsclient)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]


Your message dated Thu, 21 Aug 2008 15:43:21 -0400
with message-id <87k5eataqu.fsf@cyd.mit.edu>
and subject line Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase
has caused the Emacs bug report #581,
regarding 23.0.60; OSX: server crashes when quitting emacsclient
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
581: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=581
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 12953 bytes --]

From: Markus Triska <markus.triska@gmx.at>
To: emacs-pretest-bug@gnu.org
Subject: 23.0.60; OSX: server crashes when quitting emacsclient
Date: Sun, 20 Jul 2008 22:51:34 +0200 (CEST)
Message-ID: <20080720205134.BCB7A9D6432@mt-computer.local>


When I do:

     $ emacs -Q -nw -f server-start

and in another terminal:

     $ emacsclient -c

and then quit the client with C-x C-c, the server crashes with the
following backtrace. When I omit "-nw" for the server, it works.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0fd07d39
0x018167ad in DestroyNTable ()
(gdb) bt
#0  0x018167ad in DestroyNTable ()
#1  0x01816873 in XrmDestroyDatabase ()
#2  0x00095fb0 in x_delete_display (dpyinfo=0x214c040) at xterm.c:10523
#3  0x00096107 in x_delete_terminal (terminal=0x214c1f0) at xterm.c:10654
#4  0x00080081 in Fdelete_terminal (terminal=34914804, force=58721337) at terminal.c:336
#5  0x00011ee8 in Fdelete_frame (frame=34971156, force=58721337) at frame.c:1529
#6  0x0014544c in Ffuncall (nargs=2, args=0xbfffee80) at eval.c:3052
#7  0x0017e99b in Fbyte_code (bytestr=77604907, vector=34753444, maxdepth=6) at bytecode.c:678
#8  0x00144d2f in funcall_lambda (fun=34753700, nargs=1, arg_vector=0xbffff014) at eval.c:3229
#9  0x00145212 in Ffuncall (nargs=2, args=0xbffff010) at eval.c:3099
#10 0x0017e99b in Fbyte_code (bytestr=66970363, vector=34764708, maxdepth=3) at bytecode.c:678
#11 0x00144d2f in funcall_lambda (fun=34764852, nargs=2, arg_vector=0xbffff194) at eval.c:3229
#12 0x00145212 in Ffuncall (nargs=3, args=0xbffff190) at eval.c:3099
#13 0x0017e99b in Fbyte_code (bytestr=2019283, vector=2019300, maxdepth=4) at bytecode.c:678
#14 0x00144d2f in funcall_lambda (fun=2019236, nargs=1, arg_vector=0xbffff364) at eval.c:3229
#15 0x00145212 in Ffuncall (nargs=2, args=0xbffff360) at eval.c:3099
#16 0x001418f2 in Fcall_interactively (function=67043129, record_flag=58721289, keys=51388540) at callint.c:857
#17 0x00145425 in Ffuncall (nargs=4, args=0xbffff560) at eval.c:3048
#18 0x001455c1 in call3 (fn=58833441, arg1=67043129, arg2=58721289, arg3=58721289) at eval.c:2872
#19 0x000e446d in command_loop_1 () at keyboard.c:1912
#20 0x001435a4 in internal_condition_case (bfun=0xe400e <command_loop_1>, handlers=58760953, hfun=0xdce69 <cmd_error>) at eval.c:1511
#21 0x000d6050 in command_loop_2 () at keyboard.c:1369
#22 0x001431f6 in internal_catch (tag=58757025, func=0xd600c <command_loop_2>, arg=58721289) at eval.c:1247
#23 0x000d5df2 in command_loop () at keyboard.c:1348
#24 0x000d5eab in recursive_edit_1 () at keyboard.c:957
#25 0x000d5ff3 in Frecursive_edit () at keyboard.c:1019
#26 0x000d5031 in main (argc=5, argv=0xbffff9d8) at emacs.c:1796

Lisp Backtrace:
"delete-frame" (0xbfffee84)
"server-delete-client" (0xbffff014)
"server-save-buffers-kill-terminal" (0xbffff194)
"save-buffers-kill-terminal" (0xbffff364)
"call-interactively" (0xbffff564)
(gdb) bt full
#0  0x01816746 in DestroyLTable ()
No symbol table info available.
#1  0x0181686c in XrmDestroyDatabase ()
No symbol table info available.
#2  0x00095fb0 in x_delete_display (dpyinfo=0x21447c0) at xterm.c:10523
	t = (struct terminal *) 0x329d50
	dpyinfo = (struct x_display_info *) 0x21447c0
#3  0x00096107 in x_delete_terminal (terminal=0x2144970) at xterm.c:10654
	dpyinfo = (struct x_display_info *) 0x21447c0
	terminal = (struct terminal *) 0x83
#4  0x00080081 in Fdelete_terminal (terminal=34883956, force=58721337) at terminal.c:336
	t = (struct terminal *) 0x2144970
	terminal = 34883956
#5  0x00011ee8 in Fdelete_frame (frame=34944756, force=58721337) at frame.c:1529
	tmp = -1099628544
	f = (struct frame *) 0x21536f0
	sf = (struct frame *) 0x3800439
	kb = (struct kboard *) 0x100
#6  0x0014544c in Ffuncall (nargs=2, args=0xbfffe5c0) at eval.c:3052
	fun = -1073748672
	original_fun = 1803152
	funcar = -1099628544
	numargs = 1
	val = 3306160
	backtrace = {
  next = 0xbfffe70c, 
  function = 0xbfffe5c0, 
  args = 0xbfffe5c4, 
  nargs = 1, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0xbfffe540
	i = -1099628544
	args = (Lisp_Object *) 0x1b8390
#7  0x0017e99b in Fbyte_code (bytestr=77637499, vector=34678884, maxdepth=6) at bytecode.c:678
	op = 131
	vectorp = (Lisp_Object *) 0x2112868
	stack = {
  pc = 0x58f3344 "\210\016$A\211\026$\204o", 
  top = 0xbfffe5c4, 
  bottom = 0xbfffe5c0, 
  byte_string = 77637499, 
  byte_string_start = 0x58f32b4 "\306\307\b\205\a", 
  constants = 34678884, 
  next = 0xbfffe7c4
}
	result = 3306160
	bytestr = -1099628544
#8  0x00144d2f in funcall_lambda (fun=34627908, nargs=1, arg_vector=0xbfffe754) at eval.c:3229
	val = 131
	syms_left = 34627904
	next = 34627904
	i = 1
	optional = 1
	rest = 0
#9  0x00145212 in Ffuncall (nargs=2, args=0xbfffe750) at eval.c:3099
	fun = 34627908
	original_fun = 93438921
	funcar = -1099628544
	numargs = 1
	val = 3306160
	backtrace = {
  next = 0xbfffe88c, 
  function = 0xbfffe750, 
  args = 0xbfffe754, 
  nargs = 1, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0x2106144
	i = -1099628544
	args = (Lisp_Object *) 0x591c3c9
#10 0x0017e99b in Fbyte_code (bytestr=75536379, vector=34704900, maxdepth=3) at bytecode.c:678
	op = 131
	vectorp = (Lisp_Object *) 0x2118e08
	stack = {
  pc = 0x5906043 ")\207", 
  top = 0xbfffe754, 
  bottom = 0xbfffe750, 
  byte_string = 75536379, 
  byte_string_start = 0x5906028 "\303\b!\205\034", 
  constants = 34704900, 
  next = 0xbfffe944
}
	result = 3306160
	bytestr = -1099628544
#11 0x00144d2f in funcall_lambda (fun=34705044, nargs=2, arg_vector=0xbfffe8d4) at eval.c:3229
	val = 131
	syms_left = 34705040
	next = 34705040
	i = 2
	optional = 1
	rest = 0
#12 0x00145212 in Ffuncall (nargs=3, args=0xbfffe8d0) at eval.c:3099
	fun = 34705044
	original_fun = 67043153
	funcar = -1099628544
	numargs = 2
	val = 3306160
	backtrace = {
  next = 0xbfffea0c, 
  function = 0xbfffe8d0, 
  args = 0xbfffe8d4, 
  nargs = 2, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0x2118e94
	i = -1099628544
	args = (Lisp_Object *) 0x3feff51
#13 0x0017e99b in Fbyte_code (bytestr=2019283, vector=2019300, maxdepth=4) at bytecode.c:678
	op = 131
	vectorp = (Lisp_Object *) 0x1ecfe8
	stack = {
  pc = 0x2cc418 "*\207", 
  top = 0xbfffe8d8, 
  bottom = 0xbfffe8d0, 
  byte_string = 2019283, 
  byte_string_start = 0x2cc402 "\303\304 \305\"\304 \030\211\031\204\022", 
  constants = 2019300, 
  next = 0x0
}
	result = 3306160
	bytestr = -1099628544
#14 0x00144d2f in funcall_lambda (fun=2019236, nargs=1, arg_vector=0xbfffeaa4) at eval.c:3229
	val = 131
	syms_left = 2019232
	next = 2019232
	i = 1
	optional = 1
	rest = 0
#15 0x00145212 in Ffuncall (nargs=2, args=0xbfffeaa0) at eval.c:3099
	fun = 2019236
	original_fun = 67043129
	funcar = -1099628544
	numargs = 1
	val = 3306160
	backtrace = {
  next = 0xbfffec4c, 
  function = 0xbfffeaa0, 
  args = 0xbfffeaa4, 
  nargs = 1, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0x1ecfa4
	i = -1099628544
	args = (Lisp_Object *) 0x3feff39
#16 0x001418f2 in Fcall_interactively (function=67043129, record_flag=58721289, keys=51388540) at callint.c:857
	val = 131
	specs = 58750537
	filter_specs = 2019339
	teml = 77516529
	up_event = 58721289
	enable = 58721289
	next_event = 2
	prefix_arg = 58721289
	string = (unsigned char *) 0x2 <Address 0x2 out of bounds>
	tem = (unsigned char *) 0xbe750000 <Address 0xbe750000 out of bounds>
	i = 3306160
	j = 1
	foo = 2
	prompt1 = '\0' <repeats 99 times>
	arg_from_tty = 0
	key_count = 2
	record_then_fail = 0
	save_this_command = 67043129
	save_last_command = 77516529
	save_this_original_command = 67043129
	save_real_this_command = 67043129
#17 0x00145425 in Ffuncall (nargs=4, args=0xbfffeca0) at eval.c:3048
	fun = -1073746780
	original_fun = 58833441
	funcar = -1099628544
	numargs = 3
	val = 3306160
	backtrace = {
  next = 0x0, 
  function = 0xbfffeca0, 
  args = 0xbfffeca4, 
  nargs = 3, 
  evalargs = 0 '\0', 
  debug_on_exit = 0 '\0'
}
	internal_args = (Lisp_Object *) 0xbfffeca4
	i = -1099628544
	args = (Lisp_Object *) 0x381ba21
#18 0x001455c1 in call3 (fn=58833441, arg1=67043129, arg2=58721289, arg3=58721289) at eval.c:2872
	ret_ungc_val = 131
#19 0x000e446d in command_loop_1 () at keyboard.c:1912
	cmd = 2
	lose = 2
	nonundocount = 0
	keybuf = {192, 24, -1073746360, 2922218, 0, -1073746832, 2050659, 3298672, 58721289, 51396124, 0, 0, 0, 1330293, 2050600, 2050604, -1073746568, 1330494, 16, 58721289, 7, 0, 1, 0, -1073746596, -1073746784, 0, 0, 58721289, 67054001}
	i = 2
	prev_modiff = 15
	prev_buffer = (struct buffer *) 0x3101678
	already_adjusted = 0
#20 0x001435a4 in internal_condition_case (bfun=0xe400e <command_loop_1>, handlers=58760953, hfun=0xdce69 <cmd_error>) at eval.c:1511
	val = -1099628544
	c = {
  tag = 58721289, 
  val = 58721289, 
  next = 0xbfffee9c, 
  gcpro = 0x0, 
  jmp = {2032511, 1325783, 8096, 1324211, 58721289, 58721289, 3311984, 3298672, -1073746376, -1073746560, 31, 658, 1324360, 1507351, 3276831, 3276831, -1073807360, -1073807305}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 1, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
	h = {
  handler = 58760953, 
  var = 58721289, 
  chosen_clause = 0, 
  tag = 0xbfffed98, 
  next = 0x0
}
#21 0x000d6050 in command_loop_2 () at keyboard.c:1369
	val = 131
#22 0x001431f6 in internal_catch (tag=58757025, func=0xd600c <command_loop_2>, arg=58721289) at eval.c:1247
	c = {
  tag = 58757025, 
  val = 58721289, 
  next = 0x0, 
  gcpro = 0x0, 
  jmp = {895, 0, 8096, 1323354, 5, 0, 3320944, 3298672, -1073746152, -1073746304, 58851359, 658, 1323497, 58851351, 58851359, 58720287, 51380224, 55}, 
  backlist = 0x0, 
  handlerlist = 0x0, 
  lisp_eval_depth = 0, 
  pdlcount = 2, 
  poll_suppress_count = 1, 
  interrupt_input_blocked = 0, 
  byte_stack = 0x0
}
	tag = 131
#23 0x000d5df2 in command_loop () at keyboard.c:1348
	val = 131
#24 0x000d5eab in recursive_edit_1 () at keyboard.c:957
	val = 0
#25 0x000d5ff3 in Frecursive_edit () at keyboard.c:1019
	buffer = 58721289
#26 0x000d5031 in main (argc=5, argv=0xbffff11c) at emacs.c:1796
	dummy = -1881117246
	stack_bottom_variable = 0 '\0'
	do_initial_setlocale = 1
	skip_args = 1
	rlim = {
  rlim_cur = 8388608, 
  rlim_max = 67108864
}
	no_loadup = 0
	junk = 0x0

Lisp Backtrace:
"delete-frame" (0xbfffe5c4)
"server-delete-client" (0xbfffe754)
"server-save-buffers-kill-terminal" (0xbfffe8d4)
"save-buffers-kill-terminal" (0xbfffeaa4)
"call-interactively" (0xbfffeca4)


In GNU Emacs 23.0.60.13 (i386-apple-darwin8.11.1, GTK+ Version 2.12.9)
 of 2008-07-20 on mt-computer.local
Windowing system distributor `The XFree86 Project, Inc', version 11.0.40400000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t




[-- Attachment #3: Type: message/rfc822, Size: 1880 bytes --]

From: Chong Yidong <cyd@stupidchicken.com>
To: "İsmail Dönmez" <ismail@namtrac.org>
Cc: emacs-devel@gnu.org, 581-done@emacsbugs.donarmstrong.com
Subject: Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase
Date: Thu, 21 Aug 2008 15:43:21 -0400
Message-ID: <87k5eataqu.fsf@cyd.mit.edu>

"İsmail Dönmez" <ismail@namtrac.org> writes:

>>> So looks like there is no need to manually call XrmDestroyDatabase()
>>> anymore, attached patch removes it.
>>
>> Actually correct solution is to disable XrmDestroyDatabase() call for
>> GTK+ as done for Xt. See attached patch.
>
> Any comments on this? It fixes a frequent crash for me.

I've checked in the patch.  Thanks.

Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 21 Aug 2008 15:43:21 -0400, Chong Yidong <cyd@stupidchicken.com> said:

> "İsmail Dönmez" <ismail@namtrac.org> writes:
>>>> So looks like there is no need to manually call
>>>> XrmDestroyDatabase() anymore, attached patch removes it.
>>> 
>>> Actually correct solution is to disable XrmDestroyDatabase() call
>>> for GTK+ as done for Xt. See attached patch.
>> 
>> Any comments on this? It fixes a frequent crash for me.

> I've checked in the patch.  Thanks.

I tried reverting it, but I couldn't reproduce the crash using the
procedure in Bug#581 with Ubuntu 9.04, GTK+ build.  I also tried
setting a breakpoint to XrmDestroyDatabase, but I couldn't observe its
call from XCloseDisplay on closing an X11 display.  On the other hand,
Bug#1812 says the similar crash happens even without X toolkit on Mac
OS X 10.4.  The same binary does not crash on Mac OS X 10.5.

I think necessity of the XrmDestroyDatabase call depends on which
version of libX11 is used rather than whether GTK+ is used or not.
The relevant change in libX11 would be:

  http://lists.freedesktop.org/archives/xorg-commit-diffs/2004-March/000239.html

I confirmed that the libX11 shipped with Mac OS X 10.4 doesn't contain
the above change.

  http://www.opensource.apple.com/source/X11/X11-0.46.4/xc/lib/X11/

If we remove the XrmDestroyDatabase call unconditionally, then it
causes a memory leak when used with a newer libX11.  But that would be
better than crashing when used with an older one.

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

Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 13 May 2009 12:27:01 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

> If we remove the XrmDestroyDatabase call unconditionally, then it
> causes a memory leak when used with a newer libX11.  But that would
> be better than crashing when used with an older one.

Or maybe we can dissociate the resource database from the display
before closing it.

  #ifdef HAVE_XRMSETDATABASE
    XrmSetDatabase (dpyinfo->display, NULL);
  #else
    dpyinfo->display->db = NULL;
  #endif

Then we can ignore the difference of libX11 at least for normal close.

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

Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase

[Stefan Monnier]

> I confirmed that the libX11 shipped with Mac OS X 10.4 doesn't contain
> the above change.

>   http://www.opensource.apple.com/source/X11/X11-0.46.4/xc/lib/X11/

> If we remove the XrmDestroyDatabase call unconditionally, then it
> causes a memory leak when used with a newer libX11.  But that would be
> better than crashing when used with an older one.

OTOH, it's better to work correctly with the new code than with the old
code (better be future-proof than past-proof).  Seeing how Mac OS X 10.5
has been out for a while now, I expect most users of Emacs-23 will run
with code that would tend to leak rather than with code that
would tend to crash.

So, I'd rather just free XrmDestroyDatabase and add a note in PROBLEMS
that with older releases of libX11 there may be crashes when closing
the display.


        Stefan

Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase

[Stefan Monnier]

>> If we remove the XrmDestroyDatabase call unconditionally, then it
>> causes a memory leak when used with a newer libX11.  But that would
>> be better than crashing when used with an older one.

> Or maybe we can dissociate the resource database from the display
> before closing it.

>   #ifdef HAVE_XRMSETDATABASE
>     XrmSetDatabase (dpyinfo->display, NULL);
>   #else
dpyinfo-> display->db = NULL;
>   #endif

> Then we can ignore the difference of libX11 at least for normal close.

Sounds OK as well.


        Stefan

Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 17 May 2009 17:40:50 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>>> If we remove the XrmDestroyDatabase call unconditionally, then it
>>> causes a memory leak when used with a newer libX11.  But that would
>>> be better than crashing when used with an older one.

>> Or maybe we can dissociate the resource database from the display
>> before closing it.

>> #ifdef HAVE_XRMSETDATABASE
>> XrmSetDatabase (dpyinfo->display, NULL);
>> #else
>> dpyinfo->display->db = NULL;
>> #endif

>> Then we can ignore the difference of libX11 at least for normal close.

> Sounds OK as well.

Here is a patch.  If it's OK, I'd like to install it before the next
pretest.

				     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.1025
diff -c -p -r1.1025 xterm.c
*** src/xterm.c	2 May 2009 20:16:58 -0000	1.1025
--- src/xterm.c	18 May 2009 08:00:51 -0000
*************** x_delete_display (dpyinfo)
*** 10613,10625 ****
  	  tail->next = tail->next->next;
      }
  
-   /* Xt and GTK do this themselves.  */
- #if ! defined (USE_X_TOOLKIT) && ! defined (USE_GTK)
- #ifndef AIX		/* On AIX, XCloseDisplay calls this.  */
-   XrmDestroyDatabase (dpyinfo->xrdb);
- #endif
- #endif
- 
    xfree (dpyinfo->x_id_name);
    xfree (dpyinfo->x_dnd_atoms);
    xfree (dpyinfo->color_cells);
--- 10613,10618 ----
*************** x_delete_terminal (struct terminal *term
*** 10740,10745 ****
--- 10733,10752 ----
        x_destroy_all_bitmaps (dpyinfo);
        XSetCloseDownMode (dpyinfo->display, DestroyAll);
  
+       /* Whether or not XCloseDisplay destroys the associated resource
+ 	 database depends on the version of libX11.  To avoid both
+ 	 crash and memory leak, we dissociate the database from the
+ 	 display and then destroy dpyinfo->xrdb ourselves.  */
+ #ifdef HAVE_XRMSETDATABASE
+       XrmSetDatabase (dpyinfo->display, NULL);
+ #else
+       dpyinfo->display->db = NULL;
+ #endif
+       /* We used to call XrmDestroyDatabase from x_delete_display, but
+ 	 some older versions of libX11 crash if we call it after
+ 	 closing all the displays.  */
+       XrmDestroyDatabase (dpyinfo->xrdb);
+ 
  #ifdef USE_GTK
        xg_display_close (dpyinfo->display);
  #else

Re: [PATCH] XCloseDisplay already calls XrmDestroyDatabase

[Chong Yidong]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Here is a patch.  If it's OK, I'd like to install it before the next
> pretest.

OK, please do it.