From cz2s20d02@sneakemail.com Tue May 26 19:44:32 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 27 May 2009 02:44:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: * X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=1.1 required=4.0 tests=AWL,IMPRONONCABLE_1, IMPRONONCABLE_2,MURPHY_WRONG_WORD2 autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4R2iQp8021384 for ; Tue, 26 May 2009 19:44:28 -0700 Received: from mx10.gnu.org ([199.232.76.166]:53528) by fencepost.gnu.org with esmtp (Exim 4.67) (envelope-from ) id 1M997x-00039R-US for emacs-pretest-bug@gnu.org; Tue, 26 May 2009 22:44:26 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1M997w-0003uc-Ls for emacs-pretest-bug@gnu.org; Tue, 26 May 2009 22:44:25 -0400 Received: from sneakemail.com ([38.113.6.61]:38447 helo=sneak1.sneakemail.com) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1M997w-0003uU-8d for emacs-pretest-bug@gnu.org; Tue, 26 May 2009 22:44:24 -0400 Received: (qmail 11442 invoked by uid 508); 27 May 2009 02:44:23 -0000 Date: 27 May 2009 02:44:23 -0000 To: emacs-pretest-bug@gnu.org Subject: Crash in multi-TTY mode Encoding: 8bit From: "Shannon Jones" Message-ID: <8369-76746@sneakemail.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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 #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 , handlers=137926017, hfun=0x81229e0 ) 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 , 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 From cz2s20d02@sneakemail.com Wed May 27 00:41:50 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 27 May 2009 07:41:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=0.6 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from sneak1.sneakemail.com (sneakemail.com [38.113.6.61]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n4R7fkKZ031990 for <3399@emacsbugs.donarmstrong.com>; Wed, 27 May 2009 00:41:48 -0700 Received: (qmail 3638 invoked by uid 508); 27 May 2009 07:41:45 -0000 Date: 27 May 2009 07:41:45 -0000 To: 3399@debbugs.gnu.org Subject: More info Encoding: 8bit From: "Shannon Jones" Message-ID: <19569-51893@sneakemail.com> I made a mistake in my original report. With Xming as the X server, emacs (after server-start is run) will always segfault when you run 'emacsclient -c' and close the frame that opens. There's no need to try to time hitting C-x C-c at some magic moment. I'm using Putty with X11 forwarding. From mituharu@math.s.chiba-u.ac.jp Wed May 27 01:27:12 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 27 May 2009 08:27:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.0 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, IMPRONONCABLE_2,MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (ntp.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4R8R7QZ006138 for <3399@emacsbugs.donarmstrong.com>; Wed, 27 May 2009 01:27:08 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id ABA412C40; Wed, 27 May 2009 17:27:05 +0900 (JST) Date: Wed, 27 May 2009 17:27:05 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Shannon Jones , 3399@debbugs.gnu.org Subject: Re: bug#3399: Crash in multi-TTY mode In-Reply-To: <8369-76746@sneakemail.com> References: <8369-76746@sneakemail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On 27 May 2009 02:44:23 -0000, "Shannon Jones" 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 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 From monnier@iro.umontreal.ca Wed May 27 07:31:31 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 27 May 2009 14:31:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4REVRZn025641 for <3399@emacsbugs.donarmstrong.com>; Wed, 27 May 2009 07:31:28 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4FAPzrHErO+JxR/2dsb2JhbACBT81AhAwFhgCCPA X-IronPort-AV: E=Sophos;i="4.41,259,1241409600"; d="scan'208";a="39169587" Received: from 206-248-156-81.dsl.teksavvy.com (HELO ceviche.home) ([206.248.156.81]) by ironport2-out.teksavvy.com with ESMTP; 27 May 2009 10:31:21 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 2290CB40E5; Wed, 27 May 2009 10:31:20 -0400 (EDT) From: Stefan Monnier To: YAMAMOTO Mitsuharu Cc: 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode Message-ID: References: <8369-76746@sneakemail.com> Date: Wed, 27 May 2009 10:31:20 -0400 In-Reply-To: (YAMAMOTO Mitsuharu's message of "Wed, 27 May 2009 17:27:05 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> 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 From mituharu@math.s.chiba-u.ac.jp Wed May 27 17:47:39 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 28 May 2009 00:47:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (mathmail.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4S0lYif005911 for <3399@emacsbugs.donarmstrong.com>; Wed, 27 May 2009 17:47:36 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id DB5272C40; Thu, 28 May 2009 09:47:32 +0900 (JST) Date: Thu, 28 May 2009 09:47:32 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Stefan Monnier Cc: YAMAMOTO Mitsuharu , 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode In-Reply-To: References: <8369-76746@sneakemail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Wed, 27 May 2009 10:31:20 -0400, Stefan Monnier 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 From mituharu@math.s.chiba-u.ac.jp Wed May 27 17:55:57 2009 Received: (at control) by emacsbugs.donarmstrong.com; 28 May 2009 00:55:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.0 required=4.0 tests=AWL,MISSING_SUBJECT,NOSUBJECT autolearn=no version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (ntp.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4S0tsCW007031 for ; Wed, 27 May 2009 17:55:55 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id E2DA82C40 for ; Thu, 28 May 2009 09:55:53 +0900 (JST) Date: Thu, 28 May 2009 09:55:53 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: control@debbugs.gnu.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII merge 3399 3407 stop From mituharu@math.s.chiba-u.ac.jp Wed May 27 18:25:45 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 28 May 2009 01:25:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (mathmail.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4S1PfgA011722 for <3399@emacsbugs.donarmstrong.com>; Wed, 27 May 2009 18:25:43 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 717C42C40; Thu, 28 May 2009 10:25:41 +0900 (JST) Date: Thu, 28 May 2009 10:25:41 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Stefan Monnier Cc: 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode In-Reply-To: References: <8369-76746@sneakemail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Thu, 28 May 2009 09:47:32 +0900, YAMAMOTO Mitsuharu 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 From monnier@iro.umontreal.ca Thu May 28 06:14:17 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 28 May 2009 13:14:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.5 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4SDECAH014575 for <3399@emacsbugs.donarmstrong.com>; Thu, 28 May 2009 06:14:14 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFALwqHkrO+JxR/2dsb2JhbACBT80JhA0FhgGCPA X-IronPort-AV: E=Sophos;i="4.41,265,1241409600"; d="scan'208";a="39218603" Received: from 206-248-156-81.dsl.teksavvy.com (HELO pastel.home) ([206.248.156.81]) by ironport2-out.teksavvy.com with ESMTP; 28 May 2009 09:14:06 -0400 Received: by pastel.home (Postfix, from userid 20848) id 9B22084BF; Thu, 28 May 2009 09:14:06 -0400 (EDT) From: Stefan Monnier To: YAMAMOTO Mitsuharu Cc: 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode Message-ID: References: <8369-76746@sneakemail.com> Date: Thu, 28 May 2009 09:14:06 -0400 In-Reply-To: (YAMAMOTO Mitsuharu's message of "Thu, 28 May 2009 09:47:32 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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 From mituharu@math.s.chiba-u.ac.jp Thu May 28 20:58:28 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 29 May 2009 03:58:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (mathmail.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4T3wNsa006010 for <3399@emacsbugs.donarmstrong.com>; Thu, 28 May 2009 20:58:25 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id E93AE2C40; Fri, 29 May 2009 12:58:20 +0900 (JST) Date: Fri, 29 May 2009 12:58:20 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Stefan Monnier Cc: 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode In-Reply-To: References: <8369-76746@sneakemail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Thu, 28 May 2009 09:14:06 -0400, Stefan Monnier 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 From monnier@iro.umontreal.ca Fri May 29 07:30:20 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 29 May 2009 14:30:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.7 required=4.0 tests=HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4TEUFth002814 for <3399@emacsbugs.donarmstrong.com>; Fri, 29 May 2009 07:30:16 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAFANKNH0pFpZIv/2dsb2JhbACBT898hAwFiEQ X-IronPort-AV: E=Sophos;i="4.41,271,1241409600"; d="scan'208";a="39292009" Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 29 May 2009 10:30:09 -0400 Received: from ceviche.home ([69.165.146.47]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id KTJ62525; Fri, 29 May 2009 10:32:25 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 274B9B4261; Fri, 29 May 2009 10:30:09 -0400 (EDT) From: Stefan Monnier To: YAMAMOTO Mitsuharu Cc: 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode Message-ID: References: <8369-76746@sneakemail.com> Date: Fri, 29 May 2009 10:30:09 -0400 In-Reply-To: (YAMAMOTO Mitsuharu's message of "Fri, 29 May 2009 12:58:20 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.93 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >> 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 From mituharu@math.s.chiba-u.ac.jp Fri May 29 19:25:17 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 30 May 2009 02:25:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (ntp.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4U2PA60025691 for <3399@emacsbugs.donarmstrong.com>; Fri, 29 May 2009 19:25:12 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id C382D2C40; Sat, 30 May 2009 11:25:09 +0900 (JST) Date: Sat, 30 May 2009 11:25:09 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Stefan Monnier Cc: 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode In-Reply-To: References: <8369-76746@sneakemail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Fri, 29 May 2009 10:30:09 -0400, Stefan Monnier 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 From monnier@iro.umontreal.ca Sat May 30 13:37:15 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 30 May 2009 20:37:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.8 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4UKb8NY009417 for <3399@emacsbugs.donarmstrong.com>; Sat, 30 May 2009 13:37:10 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAAc2IUpFpZIv/2dsb2JhbACBT8xvhAwFiEU X-IronPort-AV: E=Sophos;i="4.41,276,1241409600"; d="scan'208";a="39340790" Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 30 May 2009 16:37:02 -0400 Received: from pastel.home ([69.165.146.47]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id LZR43719; Sat, 30 May 2009 16:39:19 -0400 Received: by pastel.home (Postfix, from userid 20848) id 67E2A84BF; Sat, 30 May 2009 16:37:02 -0400 (EDT) From: Stefan Monnier To: YAMAMOTO Mitsuharu Cc: 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode Message-ID: References: <8369-76746@sneakemail.com> Date: Sat, 30 May 2009 16:37:02 -0400 In-Reply-To: (YAMAMOTO Mitsuharu's message of "Sat, 30 May 2009 11:25:09 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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 From mituharu@math.s.chiba-u.ac.jp Sun May 31 00:06:03 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 31 May 2009 07:06:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.4 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from mathmail.math.s.chiba-u.ac.jp (ntp.math.s.chiba-u.ac.jp [133.82.132.2]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n4V75w6m025934 for <3399@emacsbugs.donarmstrong.com>; Sun, 31 May 2009 00:06:00 -0700 Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 897862C40; Sun, 31 May 2009 16:05:57 +0900 (JST) Date: Sun, 31 May 2009 16:05:57 +0900 Message-ID: From: YAMAMOTO Mitsuharu To: Stefan Monnier Cc: 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode In-Reply-To: References: <8369-76746@sneakemail.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Organization: Faculty of Science, Chiba University MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII >>>>> On Sat, 30 May 2009 16:37:02 -0400, Stefan Monnier 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 From monnier@iro.umontreal.ca Mon Jun 1 07:38:04 2009 Received: (at 3399) by emacsbugs.donarmstrong.com; 1 Jun 2009 14:38:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,HAS_BUG_NUMBER, MURPHY_WRONG_WORD1,MURPHY_WRONG_WORD2 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n51EbwbA022914 for <3399@emacsbugs.donarmstrong.com>; Mon, 1 Jun 2009 07:38:00 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAKeEI0pFpZIv/2dsb2JhbACBT7xMCI1xgjEfCIE0BYhF X-IronPort-AV: E=Sophos;i="4.41,284,1241409600"; d="scan'208";a="39402251" Received: from smtp.pppoe.ca (HELO smtp.teksavvy.com) ([65.39.196.238]) by ironport2-out.teksavvy.com with ESMTP; 01 Jun 2009 10:37:53 -0400 Received: from pastel.home ([69.165.146.47]) by smtp.teksavvy.com (Internet Mail Server v1.0) with ESMTP id IUP29610; Mon, 01 Jun 2009 10:40:10 -0400 Received: by pastel.home (Postfix, from userid 20848) id C72177FB6; Mon, 1 Jun 2009 10:37:52 -0400 (EDT) From: Stefan Monnier To: YAMAMOTO Mitsuharu Cc: 3399@debbugs.gnu.org, Shannon Jones Subject: Re: bug#3399: Crash in multi-TTY mode Message-ID: References: <8369-76746@sneakemail.com> Date: Mon, 01 Jun 2009 10:37:52 -0400 In-Reply-To: (YAMAMOTO Mitsuharu's message of "Sun, 31 May 2009 16:05:57 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> 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 From cyd@stupidchicken.com Fri Sep 18 16:13:32 2009 Received: (at control) by emacsbugs.donarmstrong.com; 18 Sep 2009 23:13:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.4 required=4.0 tests=AWL autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from pantheon-po32.its.yale.edu (pantheon-po32.its.yale.edu [130.132.50.88]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8INDVLe024131 for ; Fri, 18 Sep 2009 16:13:32 -0700 Received: from furry (dhcp128036014244.central.yale.edu [128.36.14.244]) (authenticated bits=0) by pantheon-po32.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id n8INDQuT024321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Sep 2009 19:13:26 -0400 Received: by furry (Postfix, from userid 1000) id 1D072C070; Fri, 18 Sep 2009 19:13:26 -0400 (EDT) From: Chong Yidong To: control@debbugs.gnu.org Subject: close 3399 Date: Fri, 18 Sep 2009 19:13:26 -0400 Message-ID: <87ws3vonhl.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) close 3399 thanks From unknown Tue Jun 17 20:18:29 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 17 Oct 2009 14:24:11 +0000 User-Agent: Fakemail v42.6.9 # A New Hope # A long time ago, in a galaxy far, far away # something happened. # # Magically this resulted in the following # action being taken, but this fake control # message doesn't tell you why it happened # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator