* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon @ 2009-04-28 14:41 Stephen Berman 2009-04-28 15:26 ` Stephen Berman 0 siblings, 1 reply; 18+ messages in thread From: Stephen Berman @ 2009-04-28 14:41 UTC (permalink / raw To: emacs-pretest-bug (This is my fourth attempt to get this into the bugtracker. On the hope that there was something about the email body and not my address that was objectionable, I am omitting the backtrace now. If this email gets through, I'll try following up with the backtrace. Whether or not that succeeds, the backtrace is available at <http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00496.html> and <http://permalink.gmane.org/gmane.emacs.devel/110453>.) Carrying out the following steps reliably crashes Emacs: 1. emacs -Q --daemon 2. emacsclient -c 3. Detach the tool bar (only possible with GTK+ build). 4. Close the client frame with C-x 5 0 5. emacsclient -c 6. Detach the tool bar => SIGSEGV If I do not start with --daemon or if I skip either step 3 or step 4, there is no crash. In GNU Emacs 23.0.92.2 (i686-pc-linux-gnu, GTK+ Version 2.14.4) of 2009-04-23 on escher Windowing system distributor `The X.Org Foundation', version 11.0.10502000 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: en_US.UTF-8 value of $XMODIFIERS: @im=local locale-coding-system: utf-8-unix default-enable-multibyte-characters: t ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-04-28 14:41 bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon Stephen Berman @ 2009-04-28 15:26 ` Stephen Berman 0 siblings, 0 replies; 18+ messages in thread From: Stephen Berman @ 2009-04-28 15:26 UTC (permalink / raw To: 3145; +Cc: emacs-pretest-bug On Tue, 28 Apr 2009 16:41:00 +0200 Stephen Berman <stephen.berman@gmx.net> wrote: > (This is my fourth attempt to get this into the bugtracker. On the hope > that there was something about the email body and not my address that > was objectionable, I am omitting the backtrace now. If this email gets > through, I'll try following up with the backtrace. Whether or not that > succeeds, the backtrace is available at > <http://lists.gnu.org/archive/html/emacs-devel/2009-04/msg00496.html> > and <http://permalink.gmane.org/gmane.emacs.devel/110453>.) > > Carrying out the following steps reliably crashes Emacs: > > 1. emacs -Q --daemon > 2. emacsclient -c > 3. Detach the tool bar (only possible with GTK+ build). > 4. Close the client frame with C-x 5 0 > 5. emacsclient -c > 6. Detach the tool bar > => SIGSEGV > > If I do not start with --daemon or if I skip either step 3 or step 4, > there is no crash. > > In GNU Emacs 23.0.92.2 (i686-pc-linux-gnu, GTK+ Version 2.14.4) > of 2009-04-23 on escher > Windowing system distributor `The X.Org Foundation', version 11.0.10502000 > 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: en_US.UTF-8 > value of $XMODIFIERS: @im=local > locale-coding-system: utf-8-unix > default-enable-multibyte-characters: t Here is the backtrace: steve@escher:~/lib/emacs/gtk/src> ./emacs -Q --daemon ("./emacs" "-Q") Starting Emacs daemon. steve@escher:~/lib/emacs/gtk/src> emacsclient -c & Waiting for Emacs...[2] 28809 steve@escher:~/lib/emacs/gtk/src> [2]+ Done emacsclient -c steve@escher:~/lib/emacs/gtk/src> emacsclient -c & Waiting for Emacs...[2] 28819 steve@escher:~/lib/emacs/gtk/src> ps aux|grep emacs | grep -v grep steve 21138 2.6 2.9 112712 60100 pts/2 S 00:12 0:47 emacs steve 28803 1.6 0.9 59288 18876 ? Ss 00:41 0:01 ./emacs -Q --daemon steve 28819 0.0 0.0 1776 460 pts/2 S 00:41 0:00 emacsclient -c steve@escher:~/lib/emacs/gtk/src> [2]+ Done emacsclient -c steve@escher:~/lib/emacs/gtk/src> emacsclient -c & Waiting for Emacs...[2] 28850 steve@escher:~/lib/emacs/gtk/src> gdb emacs 28803 GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i586-suse-linux". For bug reporting instructions, please see: <http://bugs.opensuse.org/>... Attaching to program: /Users/steve/lib/emacs/gtk/src/emacs, process 28803 Reading symbols from /usr/lib/libgtk-x11-2.0.so.0...done. Loaded symbols for /usr/lib/libgtk-x11-2.0.so.0 Reading symbols from /usr/lib/libgdk-x11-2.0.so.0...done. Loaded symbols for /usr/lib/libgdk-x11-2.0.so.0 Reading symbols from /usr/lib/libatk-1.0.so.0...done. Loaded symbols for /usr/lib/libatk-1.0.so.0 Reading symbols from /usr/lib/libgio-2.0.so.0...done. Loaded symbols for /usr/lib/libgio-2.0.so.0 Reading symbols from /usr/lib/libpangoft2-1.0.so.0...done. Loaded symbols for /usr/lib/libpangoft2-1.0.so.0 Reading symbols from /usr/lib/libgdk_pixbuf-2.0.so.0...done. Loaded symbols for /usr/lib/libgdk_pixbuf-2.0.so.0 Reading symbols from /usr/lib/libpangocairo-1.0.so.0...done. Loaded symbols for /usr/lib/libpangocairo-1.0.so.0 Reading symbols from /usr/lib/libcairo.so.2...done. Loaded symbols for /usr/lib/libcairo.so.2 Reading symbols from /usr/lib/libpango-1.0.so.0...done. Loaded symbols for /usr/lib/libpango-1.0.so.0 Reading symbols from /usr/lib/libfreetype.so.6...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /usr/lib/libfontconfig.so.1...done. Loaded symbols for /usr/lib/libfontconfig.so.1 Reading symbols from /usr/lib/libgobject-2.0.so.0...done. Loaded symbols for /usr/lib/libgobject-2.0.so.0 Reading symbols from /usr/lib/libgmodule-2.0.so.0...done. Loaded symbols for /usr/lib/libgmodule-2.0.so.0 Reading symbols from /usr/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/lib/libglib-2.0.so.0 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/lib/libSM.so.6...done. Loaded symbols for /usr/lib/libSM.so.6 Reading symbols from /usr/lib/libICE.so.6...done. Loaded symbols for /usr/lib/libICE.so.6 Reading symbols from /usr/lib/libtiff.so.3...done. Loaded symbols for /usr/lib/libtiff.so.3 Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /usr/lib/libpng12.so.0...done. Loaded symbols for /usr/lib/libpng12.so.0 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libgif.so.4...done. Loaded symbols for /usr/lib/libgif.so.4 Reading symbols from /usr/lib/libXpm.so.4...done. Loaded symbols for /usr/lib/libXpm.so.4 Reading symbols from /usr/lib/libX11.so.6...done. Loaded symbols for /usr/lib/libX11.so.6 Reading symbols from /usr/lib/libXft.so.2...done. Loaded symbols for /usr/lib/libXft.so.2 Reading symbols from /usr/lib/libXrender.so.1...done. Loaded symbols for /usr/lib/libXrender.so.1 Reading symbols from /usr/lib/libasound.so.2...done. Loaded symbols for /usr/lib/libasound.so.2 Reading symbols from /usr/lib/librsvg-2.so.2...done. Loaded symbols for /usr/lib/librsvg-2.so.2 Reading symbols from /lib/libdbus-1.so.3...done. Loaded symbols for /lib/libdbus-1.so.3 Reading symbols from /usr/lib/libgpm.so.1...done. Loaded symbols for /usr/lib/libgpm.so.1 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libXinerama.so.1...done. Loaded symbols for /usr/lib/libXinerama.so.1 Reading symbols from /usr/lib/libXi.so.6...done. Loaded symbols for /usr/lib/libXi.so.6 Reading symbols from /usr/lib/libXrandr.so.2...done. Loaded symbols for /usr/lib/libXrandr.so.2 Reading symbols from /usr/lib/libXcursor.so.1...done. Loaded symbols for /usr/lib/libXcursor.so.1 Reading symbols from /usr/lib/libXcomposite.so.1...done. Loaded symbols for /usr/lib/libXcomposite.so.1 Reading symbols from /usr/lib/libXext.so.6...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /usr/lib/libXdamage.so.1...done. Loaded symbols for /usr/lib/libXdamage.so.1 Reading symbols from /usr/lib/libXfixes.so.3...done. Loaded symbols for /usr/lib/libXfixes.so.3 Reading symbols from /usr/lib/libpixman-1.so.0...done. Loaded symbols for /usr/lib/libpixman-1.so.0 Reading symbols from /usr/lib/libxcb-render-util.so.0...done. Loaded symbols for /usr/lib/libxcb-render-util.so.0 Reading symbols from /usr/lib/libxcb-render.so.0...done. Loaded symbols for /usr/lib/libxcb-render.so.0 Reading symbols from /usr/lib/libxcb-xlib.so.0...done. Loaded symbols for /usr/lib/libxcb-xlib.so.0 Reading symbols from /usr/lib/libxcb.so.1...done. Loaded symbols for /usr/lib/libxcb.so.1 Reading symbols from /usr/lib/libXau.so.6...done. Loaded symbols for /usr/lib/libXau.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libpcre.so.0...done. Loaded symbols for /usr/lib/libpcre.so.0 Reading symbols from /lib/libselinux.so.1...done. Loaded symbols for /lib/libselinux.so.1 Reading symbols from /lib/libexpat.so.1...done. Loaded symbols for /lib/libexpat.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /usr/lib/libgsf-1.so.114...done. Loaded symbols for /usr/lib/libgsf-1.so.114 Reading symbols from /lib/libbz2.so.1...done. Loaded symbols for /lib/libbz2.so.1 Reading symbols from /usr/lib/libcroco-0.6.so.3...done. Loaded symbols for /usr/lib/libcroco-0.6.so.3 Reading symbols from /usr/lib/libxml2.so.2...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libnss_nis.so.2...done. Loaded symbols for /lib/libnss_nis.so.2 Reading symbols from /usr/lib/gtk-2.0/2.10.0/engines/libqtcurve.so...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/engines/libqtcurve.so Reading symbols from /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-xpm.so Reading symbols from /usr/lib/pango/1.6.0/modules/pango-basic-fc.so...done. Loaded symbols for /usr/lib/pango/1.6.0/modules/pango-basic-fc.so Reading symbols from /usr/lib/libgvfscommon.so.0...done. Loaded symbols for /usr/lib/libgvfscommon.so.0 Reading symbols from /usr/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/lib/libgthread-2.0.so.0 Reading symbols from /lib/libutil.so.1...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /usr/lib/gio/modules/libgvfsdbus.so...done. Loaded symbols for /usr/lib/gio/modules/libgvfsdbus.so Reading symbols from /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-png.so Reading symbols from /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so Reading symbols from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so...done. Loaded symbols for /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so 0xffffe430 in __kernel_vsyscall () SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0 TERM = xterm-256color Breakpoint 1 at 0x8124126: file /home/steve/cvsroot/emacs/src/emacs.c, line 432. Temporary breakpoint 2 at 0x8140ff9: file /home/steve/cvsroot/emacs/src/sysdep.c, line 1146. (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0xb7ab511d in gdk_pointer_grab () from /usr/lib/libgdk-x11-2.0.so.0 (gdb) bt full #0 0xb7ab511d in gdk_pointer_grab () from /usr/lib/libgdk-x11-2.0.so.0 No symbol table info available. #1 0xb7be62ed in ?? () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #2 0xb7c27ec6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #3 0xb77b14d9 in ?? () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #4 0xb77b2d8b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #5 0xb77c8dd5 in ?? () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #6 0xb77ca6bb in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #7 0xb77cacb6 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 No symbol table info available. #8 0xb7d3d3fe in ?? () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #9 0xb7c209dc in gtk_propagate_event () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #10 0xb7c21ea7 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. #11 0xb7aab6ca in ?? () from /usr/lib/libgdk-x11-2.0.so.0 No symbol table info available. #12 0xb77189a8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #13 0xb771c063 in ?? () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #14 0xb771c221 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 No symbol table info available. #15 0xb7c22094 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0 No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #16 0x080e29ea in XTread_socket (terminal=0x85a7b90, expected=1, hold_quit=0xbf8339d4) at /home/steve/cvsroot/emacs/src/xterm.c:7257 count = 0 #17 0x0812c0ae in read_avail_input (expected=1) at /home/steve/cvsroot/emacs/src/keyboard.c:7091 nr = <value optimized out> hold_quit = { kind = NO_EVENT, code = 0, part = scroll_bar_above_handle, modifiers = 0, x = 0, y = 0, timestamp = 0, padding = {0x0, 0x0}, frame_or_window = 0, arg = 0 } next = (struct terminal *) 0x83b2d40 nread = 0 err = 0 t = (struct terminal *) 0x85a7b90 #18 0x0812c1ba in handle_async_input () at /home/steve/cvsroot/emacs/src/keyboard.c:7333 nread = 0 #19 0x0812c384 in process_pending_signals () at /home/steve/cvsroot/emacs/src/keyboard.c:7349 No locals. #20 0x081cfc4d in wait_reading_process_output (time_limit=30, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=137964825, wait_proc=0x0, just_wait_proc=0) at /home/steve/cvsroot/emacs/src/process.c:4549 timeout_reduced_for_timers = 0 channel = 5 nfds = 1 ---Type <return> to continue, or q <return> to quit--- Available = { fds_bits = {32, 0 <repeats 31 times>} } Connecting = { fds_bits = {0 <repeats 32 times>} } check_connect = 0 check_delay = 0 no_avail = 5 xerrno = 11 proc = 137964825 timeout = { tv_sec = 0, tv_usec = 0 } end_time = { tv_sec = 1240440257, tv_usec = 502604 } wait_channel = -1 got_some_input = 1 #21 0x08058ec8 in sit_for (timeout=240, reading=1, do_display=1) at /home/steve/cvsroot/emacs/src/dispnew.c:6644 sec = 30 usec = 0 #22 0x08132b0a in read_char (commandflag=1, nmaps=2, maps=0xbf834060, prev_event=137964825, used_mouse_menu=0xbf834114, end_time=0x0) at /home/steve/cvsroot/emacs/src/keyboard.c:2950 tem0 = <value optimized out> delay_level = 30 buffer_size = <value optimized out> c = 137964825 local_getcjmp = {{ ---Type <return> to continue, or q <return> to quit--- __jmpbuf = {2, 137964825, 1, -1081917416, -438108237, -979188004}, __mask_was_saved = 0, __saved_mask = { __val = {137990680, 3213049672, 136170544, 140846333, 137994177, 1, 4294967295, 3213049692, 4294967295, 3213049896, 135843672, 140846333, 137994177, 137990684, 1240440226, 136153614, 1536, 144828557, 144828541, 137175131, 3213049440, 0, 999999, 136086640, 1, 0, 0, 8192, 0, 0, 0, 0} } }} save_jump = {{ __jmpbuf = {0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0 <repeats 32 times>} } }} key_already_recorded = 0 tem = 0 save = <value optimized out> previous_echo_area_message = 137964825 also_record = 137964825 reread = 0 polling_stopped_here = <value optimized out> orig_kboard = (struct kboard *) 0x8994098 #23 0x081340d1 in read_key_sequence (keybuf=0xbf8341c4, bufsize=30, prompt=137964825, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at /home/steve/cvsroot/emacs/src/keyboard.c:9458 interrupted_kboard = (KBOARD *) 0x8994098 key = 0 used_mouse_menu = 0 echo_local_start = 0 last_real_key_start = 0 ---Type <return> to continue, or q <return> to quit--- keys_local_start = 0 local_first_binding = 0 from_string = 137964825 count = 2 t = 0 echo_start = 0 keys_start = 0 nmaps = 2 nmaps_allocated = 2 defs = (Lisp_Object * volatile) 0xbf834040 submaps = (Lisp_Object * volatile) 0xbf834060 orig_local_map = 140868229 orig_keymap = 137964825 localized_local_map = 0 first_binding = 0 first_unbound = 31 mock_input = 0 fkey = { parent = 139238973, map = 139238973, start = 0, end = 0 } keytran = { parent = 137958269, map = 137958269, start = 0, end = 0 } indec = { parent = 139238989, map = 139238989, ---Type <return> to continue, or q <return> to quit--- start = 0, end = 0 } shift_translated = 0 delayed_switch_frame = 137964825 original_uppercase = 137990680 original_uppercase_position = -1 starting_buffer = (struct buffer *) 0x8399218 fake_prefixed_keys = 137964825 #24 0x081361f4 in command_loop_1 () at /home/steve/cvsroot/emacs/src/keyboard.c:1642 cmd = <value optimized out> lose = <value optimized out> nonundocount = 0 keybuf = {144828541, 424, 384, 0, 0, 0, -1208799616, -1472036457, 1011, 88216588, 59, -1223201480, -1223206568, 0, 0, 0, 1, 1012, -1224823032, 0, -1081916888, -1081917040, 0, 0, 137964825, 138410401, 0, 138492872, 138492856, -1081916856} i = <value optimized out> prev_modiff = 11 prev_buffer = (struct buffer *) 0x8399218 already_adjusted = 0 #25 0x08192850 in internal_condition_case (bfun=0x8136010 <command_loop_1>, handlers=138007961, hfun=0x8130870 <cmd_error>) at /home/steve/cvsroot/emacs/src/eval.c:1512 val = <value optimized out> c = { tag = 137964825, val = 137964825, next = 0xbf834370, gcpro = 0x0, jmp = {{ __jmpbuf = {0, 138492872, 138492856, -1081916616, -451043405, -775349028}, __mask_was_saved = 0, ---Type <return> to continue, or q <return> to quit--- __saved_mask = { __val = {3086186104, 134545375, 3070144264, 0, 0, 134544682, 3073952340, 3086184436, 3213050268, 3070144124, 3213050320, 3086096887, 3073163584, 139522968, 139522968, 3073159156, 3073952400, 3213050896, 3213050604, 3213050896, 3213050744, 135530500, 2, 3213050756, 3071782008, 3073952400, 4294967294, 4294967295, 3086184436, 3086186104, 134523852, 3213050688} } }}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } h = { handler = 138007961, var = 137964825, chosen_clause = 1, tag = 0xbf83425c, next = 0x0 } #26 0x0812fdb5 in command_loop_2 () at /home/steve/cvsroot/emacs/src/keyboard.c:1359 val = 0 #27 0x0819292a in internal_catch (tag=138003985, func=0x812fd90 <command_loop_2>, arg=137964825) at /home/steve/cvsroot/emacs/src/eval.c:1248 c = { tag = 138003985, val = 137964825, next = 0x0, gcpro = 0x0, ---Type <return> to continue, or q <return> to quit--- jmp = {{ __jmpbuf = {0, 138492872, 138492856, -1081916360, -450887757, -775224100}, __mask_was_saved = 0, __saved_mask = { __val = {0, 0, 0, 0, 0, 0, 3072202510, 0, 0, 0, 0, 0, 0, 0, 3073163736, 192, 0, 3073163640, 177, 22, 138204104, 138204458, 137990680, 3213050920, 135806139, 138204105, 138204458, 137964825, 137990680, 137964849, 138204456, 0} } }}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0 } #28 0x081306bf in command_loop () at /home/steve/cvsroot/emacs/src/keyboard.c:1338 No locals. #29 0x08130a4b in recursive_edit_1 () at /home/steve/cvsroot/emacs/src/keyboard.c:953 val = <value optimized out> #30 0x08130b94 in Frecursive_edit () at /home/steve/cvsroot/emacs/src/keyboard.c:1015 buffer = 137964825 #31 0x0812514f in main (argc=3, argv=0xbf834844) at /home/steve/cvsroot/emacs/src/emacs.c:1852 dummy = 139782288 stack_bottom_variable = 8 '\b' do_initial_setlocale = 1 skip_args = 1 rlim = { rlim_cur = 8388608, rlim_max = 18446744073709551615 } ---Type <return> to continue, or q <return> to quit--- no_loadup = 0 junk = 0x0 dname_arg = 0x0 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0xffffe430 in __kernel_vsyscall () (gdb) c Continuing. Program terminated with signal SIGSEGV, Segmentation fault. The program no longer exists. (gdb) q ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon
@ 2009-04-30 1:05 Chong Yidong
2009-04-30 7:57 ` Jan Djärv
0 siblings, 1 reply; 18+ messages in thread
From: Chong Yidong @ 2009-04-30 1:05 UTC (permalink / raw
To: Jan Djärv; +Cc: 3145, Stephen Berman
Stephen Berman <stephen.berman@gmx.net> wrote:
> Carrying out the following steps reliably crashes Emacs:
>
> 1. emacs -Q --daemon
> 2. emacsclient -c
> 3. Detach the tool bar (only possible with GTK+ build).
> 4. Close the client frame with C-x 5 0
> 5. emacsclient -c
> 6. Detach the tool bar
> => SIGSEGV
Actually, daemon mode is not needed. You can also do this:
1. emacs -Q -nw
2. M-x make-frame-on-display RET :0.0 RET
3. Detach the tool bar
4. Close the client frame with C-x 5 0
5. M-x make-frame-on-display RET :0.0 RET
6. Detach the tool bar
=> SIGSEGV
Jan, could you try to debug this? It may be another manifestation of
the problems we've been having with GTK and closing X connections.
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-04-30 1:05 Chong Yidong @ 2009-04-30 7:57 ` Jan Djärv 2009-05-02 16:51 ` Jan Djärv 0 siblings, 1 reply; 18+ messages in thread From: Jan Djärv @ 2009-04-30 7:57 UTC (permalink / raw To: Chong Yidong; +Cc: 3145, Stephen Berman Chong Yidong skrev: > Stephen Berman <stephen.berman@gmx.net> wrote: > >> Carrying out the following steps reliably crashes Emacs: >> >> 1. emacs -Q --daemon >> 2. emacsclient -c >> 3. Detach the tool bar (only possible with GTK+ build). >> 4. Close the client frame with C-x 5 0 >> 5. emacsclient -c >> 6. Detach the tool bar >> => SIGSEGV > > Actually, daemon mode is not needed. You can also do this: > > 1. emacs -Q -nw > 2. M-x make-frame-on-display RET :0.0 RET > 3. Detach the tool bar > 4. Close the client frame with C-x 5 0 > 5. M-x make-frame-on-display RET :0.0 RET > 6. Detach the tool bar > => SIGSEGV > > Jan, could you try to debug this? It may be another manifestation of > the problems we've been having with GTK and closing X connections. It looks like it. The window for the detached tool bar is created and managed by Gtk+ and is not deleted when the display is removed it seems. I'll see if we can work around it. Jan D. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-04-30 7:57 ` Jan Djärv @ 2009-05-02 16:51 ` Jan Djärv 2009-05-02 17:10 ` Chong Yidong 2009-05-02 23:35 ` Stephen Berman 0 siblings, 2 replies; 18+ messages in thread From: Jan Djärv @ 2009-05-02 16:51 UTC (permalink / raw To: Chong Yidong; +Cc: 3145, Stephen Berman Sorry, no workaround is possible. The part in Gtk+ that handles detaching uses a hidden window which it stores in a static variable. So it get created on the first display, but is still used on the second, but that is not a valid window anymore: static GtkWidget * gtk_handle_box_get_invisible (void) { static GtkWidget *handle_box_invisible = NULL; if (!handle_box_invisible) { handle_box_invisible = gtk_invisible_new (); gtk_widget_show (handle_box_invisible); } return handle_box_invisible; } This is another instance of the "there is just one display and it is always open"-mindset of Gtk+. I have filed a Gtk+ bug on this (http://bugzilla.gnome.org/show_bug.cgi?id=581110). Not sure what we should do about this bug though. Keep it until Gtk+ fixes/rejects the bug report or close it? Jan D. > > > Chong Yidong skrev: >> Stephen Berman <stephen.berman@gmx.net> wrote: >> >>> Carrying out the following steps reliably crashes Emacs: >>> >>> 1. emacs -Q --daemon >>> 2. emacsclient -c >>> 3. Detach the tool bar (only possible with GTK+ build). >>> 4. Close the client frame with C-x 5 0 >>> 5. emacsclient -c >>> 6. Detach the tool bar >>> => SIGSEGV >> >> Actually, daemon mode is not needed. You can also do this: >> >> 1. emacs -Q -nw >> 2. M-x make-frame-on-display RET :0.0 RET >> 3. Detach the tool bar >> 4. Close the client frame with C-x 5 0 >> 5. M-x make-frame-on-display RET :0.0 RET >> 6. Detach the tool bar >> => SIGSEGV >> >> Jan, could you try to debug this? It may be another manifestation of >> the problems we've been having with GTK and closing X connections. > > It looks like it. The window for the detached tool bar is created and > managed by Gtk+ and is not deleted when the display is removed it seems. > > I'll see if we can work around it. > > Jan D. > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-05-02 16:51 ` Jan Djärv @ 2009-05-02 17:10 ` Chong Yidong 2009-05-02 23:35 ` Stephen Berman 1 sibling, 0 replies; 18+ messages in thread From: Chong Yidong @ 2009-05-02 17:10 UTC (permalink / raw To: Jan Djärv; +Cc: 3145, Stephen Berman > This is another instance of the "there is just one display and it is > always open"-mindset of Gtk+. > > I have filed a Gtk+ bug on this > (http://bugzilla.gnome.org/show_bug.cgi?id=581110). Not sure what we > should do about this bug though. Keep it until Gtk+ fixes/rejects the > bug report or close it? No harm keeping the bug open, I think. Thanks for investigating. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-05-02 16:51 ` Jan Djärv 2009-05-02 17:10 ` Chong Yidong @ 2009-05-02 23:35 ` Stephen Berman 2009-05-03 17:19 ` Jan Djärv 2009-05-03 21:30 ` Richard M Stallman 1 sibling, 2 replies; 18+ messages in thread From: Stephen Berman @ 2009-05-02 23:35 UTC (permalink / raw To: Jan Djärv; +Cc: 3145, Chong Yidong On Sat, 02 May 2009 18:51:14 +0200 Jan Djärv <jan.h.d@swipnet.se> wrote: > Sorry, no workaround is possible. > The part in Gtk+ that handles detaching uses a hidden window which it stores > in a static variable. So it get created on the first display, but is still > used on the second, but that is not a valid window anymore: [...] > This is another instance of the "there is just one display and it is always > open"-mindset of Gtk+. > > I have filed a Gtk+ bug on this > (http://bugzilla.gnome.org/show_bug.cgi?id=581110). Not sure what we should do > about this bug though. Keep it until Gtk+ fixes/rejects the bug report or > close it? As long as this does not change in GTK+ and no workaround is possible in Emacs, I (sadly) think you should seriously consider disabling detaching the tool bar in the GTK+ build. When used in conjunction with --daemon it is a ticking time bomb for data loss because of the crash it causes. I don't make this suggestion lightly, since detaching the tool bar is to me an acceptable workaround for the very annoying shrinking frame bug (see bug#3195), but precluding a crash and possible data loss should probably take precedence over avoiding annoyance. Steve Berman ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-05-02 23:35 ` Stephen Berman @ 2009-05-03 17:19 ` Jan Djärv 2009-05-03 18:24 ` Dan Nicolaescu 2009-05-03 21:30 ` Richard M Stallman 1 sibling, 1 reply; 18+ messages in thread From: Jan Djärv @ 2009-05-03 17:19 UTC (permalink / raw To: Stephen Berman; +Cc: 3145, Chong Yidong Stephen Berman skrev: > > As long as this does not change in GTK+ and no workaround is possible in > Emacs, I (sadly) think you should seriously consider disabling detaching > the tool bar in the GTK+ build. When used in conjunction with --daemon > it is a ticking time bomb for data loss because of the crash it causes. > I don't make this suggestion lightly, since detaching the tool bar is to > me an acceptable workaround for the very annoying shrinking frame bug > (see bug#3195), but precluding a crash and possible data loss should > probably take precedence over avoiding annoyance. > I don't mind disabling detaching if it is OK in the current code freeze. Jan D. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-05-03 17:19 ` Jan Djärv @ 2009-05-03 18:24 ` Dan Nicolaescu 2009-05-03 20:25 ` Chong Yidong 0 siblings, 1 reply; 18+ messages in thread From: Dan Nicolaescu @ 2009-05-03 18:24 UTC (permalink / raw To: Jan Djärv; +Cc: 3145, Chong Yidong, Stephen Berman Jan Djärv <jan.h.d@swipnet.se> writes: > Stephen Berman skrev: > > > > > As long as this does not change in GTK+ and no workaround is possible in > > Emacs, I (sadly) think you should seriously consider disabling detaching > > the tool bar in the GTK+ build. When used in conjunction with --daemon > > it is a ticking time bomb for data loss because of the crash it causes. > > I don't make this suggestion lightly, since detaching the tool bar is to > > me an acceptable workaround for the very annoying shrinking frame bug > > (see bug#3195), but precluding a crash and possible data loss should > > probably take precedence over avoiding annoyance. > > > > I don't mind disabling detaching if it is OK in the current code freeze. IMHO detaching the toolbar is a red herring here. Yes, there on big valid reason to disable detaching the toolbar: it seems that detaching the toolbar is disabled by default by (almost?) all Gtk+ applications. The ticking time bomb is actually using an emacs compiled with the Gtk+ support in conjunction with multi-tty. emacsclient + kill emacsclient + emacsclient results in a crash. IMO we need at least a big fat warning in NEWS (or some other very prominent place) with a reference to the Gtk+ bug to make users aware of the problem. We've had many bug reports about this, we'll only get more after the release. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-05-03 18:24 ` Dan Nicolaescu @ 2009-05-03 20:25 ` Chong Yidong 0 siblings, 0 replies; 18+ messages in thread From: Chong Yidong @ 2009-05-03 20:25 UTC (permalink / raw To: Dan Nicolaescu; +Cc: 3145, Jan Djärv, Stephen Berman Dan Nicolaescu <dann@ics.uci.edu> writes: >> I don't mind disabling detaching if it is OK in the current code >> freeze. I'd rather not. > IMHO detaching the toolbar is a red herring here. The ticking time > bomb is actually using an emacs compiled with the Gtk+ support in > conjunction with multi-tty. emacsclient + kill emacsclient + > emacsclient results in a crash. > > IMO we need at least a big fat warning in NEWS (or some other very > prominent place) with a reference to the Gtk+ bug to make users aware > of the problem. We've had many bug reports about this, we'll only get > more after the release. We have an entry in PROBLEMS, which may need to be updated. I have no objection to adding a warning to NEWS as well. Could someone try to summarize, as well as you can, the circumstances that are likely to lead to lead to a crash? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-05-02 23:35 ` Stephen Berman 2009-05-03 17:19 ` Jan Djärv @ 2009-05-03 21:30 ` Richard M Stallman 2009-05-04 20:17 ` Jan Djärv 1 sibling, 1 reply; 18+ messages in thread From: Richard M Stallman @ 2009-05-03 21:30 UTC (permalink / raw To: Stephen Berman, 3145; +Cc: 3145, cyd, jan.h.d It would be useful to make Emacs detect this case and give a clean error message such as "Due to GTK+ bug number XYZ, what you want to do is impossible", rather than just crashing. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-05-03 21:30 ` Richard M Stallman @ 2009-05-04 20:17 ` Jan Djärv 2009-08-04 19:25 ` Sven Joachim 0 siblings, 1 reply; 18+ messages in thread From: Jan Djärv @ 2009-05-04 20:17 UTC (permalink / raw To: rms; +Cc: 3145, cyd, Stephen Berman Richard M Stallman skrev: > It would be useful to make Emacs detect this case and give a clean > error message such as "Due to GTK+ bug number XYZ, what you want to do > is impossible", rather than just crashing. The good news is that the bug has been marked as FIXED. But I don't know in which Gtk+ version the fix will appear in. The only way to detect this particular bug is by checking version numbers. Jan D. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-05-04 20:17 ` Jan Djärv @ 2009-08-04 19:25 ` Sven Joachim 2009-08-05 9:41 ` Jan Djärv 0 siblings, 1 reply; 18+ messages in thread From: Sven Joachim @ 2009-08-04 19:25 UTC (permalink / raw To: Jan Djärv; +Cc: 3145, cyd, Stephen Berman, rms On 2009-05-04 22:17 +0200, Jan Djärv wrote: > Richard M Stallman skrev: >> It would be useful to make Emacs detect this case and give a clean >> error message such as "Due to GTK+ bug number XYZ, what you want to do >> is impossible", rather than just crashing. > > The good news is that the bug has been marked as FIXED. But I don't > know in which Gtk+ version the fix will appear in. The only way to > detect this particular bug is by checking version numbers. For the record, I see the following in /usr/share/doc/libgtk2.0-common/changelog.gz: ,---- | commit 00524901e1393618e469dd9a8f224401b8ba7e35 | Author: Matthias Clasen <mclasen@redhat.com> | Date: Sun May 3 22:27:12 2009 -0400 | | Make GtkHandleBox work on multiple displays | | gtk/gtkhandlebox.c | 1 + | 1 files changed, 1 insertions(+), 0 deletions(-) `---- This is included in GTK+ 2.16.2, but the recipe to crash Emacs from the original report still works in GNU Emacs 23.1.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 2.16.5) of 2009-08-04 on turtle . Note that this recipe does not even involve multiple displays. Sven ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-08-04 19:25 ` Sven Joachim @ 2009-08-05 9:41 ` Jan Djärv 2011-09-16 20:34 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 18+ messages in thread From: Jan Djärv @ 2009-08-05 9:41 UTC (permalink / raw To: Sven Joachim; +Cc: 3145, cyd, Stephen Berman, rms Sven Joachim skrev: > On 2009-05-04 22:17 +0200, Jan Djärv wrote: > >> Richard M Stallman skrev: >>> It would be useful to make Emacs detect this case and give a clean >>> error message such as "Due to GTK+ bug number XYZ, what you want to do >>> is impossible", rather than just crashing. >> The good news is that the bug has been marked as FIXED. But I don't >> know in which Gtk+ version the fix will appear in. The only way to >> detect this particular bug is by checking version numbers. > > For the record, I see the following in > /usr/share/doc/libgtk2.0-common/changelog.gz: > > ,---- > | commit 00524901e1393618e469dd9a8f224401b8ba7e35 > | Author: Matthias Clasen <mclasen@redhat.com> > | Date: Sun May 3 22:27:12 2009 -0400 > | > | Make GtkHandleBox work on multiple displays > | > | gtk/gtkhandlebox.c | 1 + > | 1 files changed, 1 insertions(+), 0 deletions(-) > `---- > > This is included in GTK+ 2.16.2, but the recipe to crash Emacs from the > original report still works in > GNU Emacs 23.1.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 2.16.5) > of 2009-08-04 on turtle . > > Note that this recipe does not even involve multiple displays. > You are correct, the fix in Gtk+ is no good, it is obvious that they didn't test the fix. I've reopened the Gtk+ bug for this with new information: http://bugzilla.gnome.org/show_bug.cgi?id=581110 Hopefully a better fix will come. Jan D. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2009-08-05 9:41 ` Jan Djärv @ 2011-09-16 20:34 ` Lars Magne Ingebrigtsen 2011-09-16 22:29 ` Jan Djärv 2016-04-10 22:40 ` Alan Third 0 siblings, 2 replies; 18+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-09-16 20:34 UTC (permalink / raw To: Jan Djärv; +Cc: 3145, cyd, Stephen Berman, Sven Joachim, rms Jan Djärv <jan.h.d@swipnet.se> writes: > You are correct, the fix in Gtk+ is no good, it is obvious that they > didn't test the fix. > I've reopened the Gtk+ bug for this with new information: > http://bugzilla.gnome.org/show_bug.cgi?id=581110 > > Hopefully a better fix will come. This bug remains with "severity: critical" and no fix in the gtk bug tracker. So perhaps Emacs should do a workaround anyway? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2011-09-16 20:34 ` Lars Magne Ingebrigtsen @ 2011-09-16 22:29 ` Jan Djärv 2016-04-10 22:40 ` Alan Third 1 sibling, 0 replies; 18+ messages in thread From: Jan Djärv @ 2011-09-16 22:29 UTC (permalink / raw To: Lars Magne Ingebrigtsen Cc: 3145@debbugs.gnu.org, cyd@stupidchicken.com, Stephen Berman, Sven Joachim, rms@gnu.org Hello. 16 sep 2011 kl. 22:34 skrev Lars Magne Ingebrigtsen <larsi@gnus.org>: > Jan Djärv <jan.h.d@swipnet.se> writes: > >> You are correct, the fix in Gtk+ is no good, it is obvious that they >> didn't test the fix. >> I've reopened the Gtk+ bug for this with new information: >> http://bugzilla.gnome.org/show_bug.cgi?id=581110 >> >> Hopefully a better fix will come. > > This bug remains with "severity: critical" and no fix in the gtk bug > tracker. So perhaps Emacs should do a workaround anyway? > The only workaround that works is not having detachable toolbars. I'm not opposed to that. Detachable toolbars is on its way out from Gtk+ anyway. I'm surprised they are in Gtk+ 3.0. Jan D. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2011-09-16 20:34 ` Lars Magne Ingebrigtsen 2011-09-16 22:29 ` Jan Djärv @ 2016-04-10 22:40 ` Alan Third 2016-04-11 8:28 ` Stephen Berman 1 sibling, 1 reply; 18+ messages in thread From: Alan Third @ 2016-04-10 22:40 UTC (permalink / raw To: Lars Magne Ingebrigtsen Cc: Jan Djärv, rms, cyd, Stephen Berman, Sven Joachim, 3145 Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Jan Djärv <jan.h.d@swipnet.se> writes: > >> You are correct, the fix in Gtk+ is no good, it is obvious that they >> didn't test the fix. >> I've reopened the Gtk+ bug for this with new information: >> http://bugzilla.gnome.org/show_bug.cgi?id=581110 >> >> Hopefully a better fix will come. > > This bug remains with "severity: critical" and no fix in the gtk bug > tracker. So perhaps Emacs should do a workaround anyway? The Gtk+ bug is now marked "resolved obsolete" as the widget is deprecated. Does anyone know if it was ever fixed or if it's even still an issue? (I don't have a Gtk+ set-up to test on.) -- Alan Third ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon 2016-04-10 22:40 ` Alan Third @ 2016-04-11 8:28 ` Stephen Berman 0 siblings, 0 replies; 18+ messages in thread From: Stephen Berman @ 2016-04-11 8:28 UTC (permalink / raw To: Alan Third Cc: rms, cyd, Lars Magne Ingebrigtsen, Jan Djärv, Sven Joachim, 3145 On Sun, 10 Apr 2016 23:40:06 +0100 Alan Third <alan@idiocy.org> wrote: > Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > >> Jan Djärv <jan.h.d@swipnet.se> writes: >> >>> You are correct, the fix in Gtk+ is no good, it is obvious that they >>> didn't test the fix. >>> I've reopened the Gtk+ bug for this with new information: >>> http://bugzilla.gnome.org/show_bug.cgi?id=581110 >>> >>> Hopefully a better fix will come. >> >> This bug remains with "severity: critical" and no fix in the gtk bug >> tracker. So perhaps Emacs should do a workaround anyway? > > The Gtk+ bug is now marked "resolved obsolete" as the widget is > deprecated. Does anyone know if it was ever fixed or if it's even still > an issue? (I don't have a Gtk+ set-up to test on.) With GNU Emacs 24.3.1 (x86_64-suse-linux-gnu, GTK+ Version 3.14.2) of 2014-10-15 on build05 I do not get a crash by executing either of the two recipes given in this bug thread, so I assume it was either fixed somewhere or maybe it was only a bug with GTK2 (that's what I was using when I reported the bug, but I cannot currently test that). Moreover, it's a nonissue for Emacs 25, since there the GTK+ tool bar is no longer detachable. So I think this bug can be closed. Steve Berman ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2016-04-11 8:28 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-04-28 14:41 bug#3145: 23.0.92; detaching GTK+ tool bar crashes emacs --daemon Stephen Berman 2009-04-28 15:26 ` Stephen Berman -- strict thread matches above, loose matches on Subject: below -- 2009-04-30 1:05 Chong Yidong 2009-04-30 7:57 ` Jan Djärv 2009-05-02 16:51 ` Jan Djärv 2009-05-02 17:10 ` Chong Yidong 2009-05-02 23:35 ` Stephen Berman 2009-05-03 17:19 ` Jan Djärv 2009-05-03 18:24 ` Dan Nicolaescu 2009-05-03 20:25 ` Chong Yidong 2009-05-03 21:30 ` Richard M Stallman 2009-05-04 20:17 ` Jan Djärv 2009-08-04 19:25 ` Sven Joachim 2009-08-05 9:41 ` Jan Djärv 2011-09-16 20:34 ` Lars Magne Ingebrigtsen 2011-09-16 22:29 ` Jan Djärv 2016-04-10 22:40 ` Alan Third 2016-04-11 8:28 ` Stephen Berman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.