* 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.