* Killing a frame sometimes kills emacs
@ 2011-08-31 20:16 Tassilo Horn
2011-08-31 20:51 ` joakim
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-08-31 20:16 UTC (permalink / raw)
To: emacs-devel
Hi all,
since lately, I have a really annoying problem with the current emacs
trunk. My current emacs is about 4 days old, but I've hit that problem
already when I came back from holiday three weeks ago.
The problem is that frequently, killing an emacs X11 frame kills the
complete emacs instance. It doesn't crash or so, but it's just like if
I had called `kill-emacs'.
The usual steps are:
1. Start emacs (the server is activated from my .emacs)
2. Work for several hours without issues
3. emacsclient -c [maybe-a-file.txt]
4. kill the client frame with C-x 5 0, C-x #, or the X knob at the
window decoration ==> BANG! Emacs is gone...
My problem is that I'm totally unable to reproduce the issue. I've just
tried to activate and use all packages/modes I usually work with (Gnus,
Org, SLIME/Clojure, Elisp, AUCTeX, rcirc) step by step, but still
creating and killing frames works as it's supposed to do.
Do you have any suggestions on how to debug this issue?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-08-31 20:16 Killing a frame sometimes kills emacs Tassilo Horn
@ 2011-08-31 20:51 ` joakim
2011-08-31 23:06 ` chad
2011-09-01 2:53 ` Eli Zaretskii
2 siblings, 0 replies; 39+ messages in thread
From: joakim @ 2011-08-31 20:51 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Tassilo Horn <tassilo@member.fsf.org> writes:
> Hi all,
>
> since lately, I have a really annoying problem with the current emacs
> trunk. My current emacs is about 4 days old, but I've hit that problem
> already when I came back from holiday three weeks ago.
>
> The problem is that frequently, killing an emacs X11 frame kills the
> complete emacs instance. It doesn't crash or so, but it's just like if
> I had called `kill-emacs'.
>
> The usual steps are:
>
> 1. Start emacs (the server is activated from my .emacs)
> 2. Work for several hours without issues
> 3. emacsclient -c [maybe-a-file.txt]
> 4. kill the client frame with C-x 5 0, C-x #, or the X knob at the
> window decoration ==> BANG! Emacs is gone...
>
> My problem is that I'm totally unable to reproduce the issue. I've just
> tried to activate and use all packages/modes I usually work with (Gnus,
> Org, SLIME/Clojure, Elisp, AUCTeX, rcirc) step by step, but still
> creating and killing frames works as it's supposed to do.
>
> Do you have any suggestions on how to debug this issue?
>
> Bye,
> Tassilo
Not much help, but I use the below bash script to run Emacs.
That way I can get a backtrace most of the time which helps.
(I'm also suffering from some weirdo heisenbug. Lately it has been
something involving overlays and pop_it at xdisp.c:5492. It might be
something local though)
#!/bin/sh
#cd to src dir to load emacs gdb macros
cd ~/build_myprojs/emacsnew/emacs.bzr/xwidget/src/
xterm -e gdb -ex run emacs
--
Joakim Verona
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-08-31 20:16 Killing a frame sometimes kills emacs Tassilo Horn
2011-08-31 20:51 ` joakim
@ 2011-08-31 23:06 ` chad
2011-09-01 2:53 ` Eli Zaretskii
2 siblings, 0 replies; 39+ messages in thread
From: chad @ 2011-08-31 23:06 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
Do you have a non-nill confirm-kill-emacs? If not, try setting it. If so,
have you tried (debug-on-entry 'kill-emacs)?
Hope that helps,
*Chad
On Aug 31, 2011, at 1:16 PM, Tassilo Horn wrote:
> Do you have any suggestions on how to debug this issue?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-08-31 20:16 Killing a frame sometimes kills emacs Tassilo Horn
2011-08-31 20:51 ` joakim
2011-08-31 23:06 ` chad
@ 2011-09-01 2:53 ` Eli Zaretskii
2011-09-01 7:04 ` Tassilo Horn
2011-09-01 10:09 ` Tassilo Horn
2 siblings, 2 replies; 39+ messages in thread
From: Eli Zaretskii @ 2011-09-01 2:53 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Wed, 31 Aug 2011 22:16:55 +0200
>
> Do you have any suggestions on how to debug this issue?
Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
this happens again, tell use who called it by showing the backtrace.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 2:53 ` Eli Zaretskii
@ 2011-09-01 7:04 ` Tassilo Horn
2011-09-01 10:09 ` Tassilo Horn
1 sibling, 0 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-09-01 7:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Tassilo Horn <tassilo@member.fsf.org>
>> Date: Wed, 31 Aug 2011 22:16:55 +0200
>>
>> Do you have any suggestions on how to debug this issue?
>
> Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
> this happens again, tell use who called it by showing the backtrace.
Ok, breakpoint is set. Let's see what happens...
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 2:53 ` Eli Zaretskii
2011-09-01 7:04 ` Tassilo Horn
@ 2011-09-01 10:09 ` Tassilo Horn
2011-09-01 10:27 ` Eli Zaretskii
2011-09-01 10:33 ` Andreas Schwab
1 sibling, 2 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-09-01 10:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
Hi Eli,
>> From: Tassilo Horn <tassilo@member.fsf.org>
>> Date: Wed, 31 Aug 2011 22:16:55 +0200
>>
>> Do you have any suggestions on how to debug this issue?
>
> Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
> this happens again, tell use who called it by showing the backtrace.
It turned out to be a crash, not something calling Fkill_emacs. Here's
the backtrace:
--8<---------------cut here---------------start------------->8---
Breakpoint 1 at 0x4f23dd: file emacs.c, line 1985.
Starting program: /usr/bin/emacs-24
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6e80700 (LWP 31725)]
[New Thread 0x7fffe667f700 (LWP 31726)]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
#0 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
No symbol table info available.
#1 0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#3 0x00007ffff7599f0e in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#4 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5 0x00007ffff758c5d6 in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#6 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7 0x00000000004e157c in xg_display_close (dpy=0x6ca0020) at gtkutil.c:182
gdpy = 0xd682e0
#8 0x00000000004afc49 in x_delete_terminal (terminal=<optimized out>)
at xterm.c:10607
dpyinfo = 0x698d3e0
#9 0x00000000004a40f2 in Fdelete_terminal (terminal=107998581,
force=<optimized out>) at terminal.c:345
t = 0x66fed70
#10 0x00000000004235cc in delete_frame (frame=99991829, force=<optimized out>)
at frame.c:1379
tmp = <optimized out>
terminal = <optimized out>
f = 0x5f5c110
sf = 0x121b7e0
kb = 0x0
minibuffer_selected = 0
tooltip_frame = 0
#11 0x000000000042382a in Fdelete_frame (frame=<optimized out>,
force=<optimized out>) at frame.c:1516
No locals.
#12 0x000000000055d81f in Ffuncall (nargs=3, args=0x7fffffffc9f0)
at eval.c:2993
fun = <optimized out>
original_fun = <optimized out>
funcar = <optimized out>
numargs = <optimized out>
lisp_numargs = <optimized out>
val = <optimized out>
backtrace = {next = 0x7fffffffcb70, function = 0x7fffffffc9f0,
args = 0x7fffffffc9f8, nargs = 2, debug_on_exit = 0}
internal_args = 0x7fffffffc9f8
i = <optimized out>
#13 0x000000000058fafe in exec_byte_code (bytestr=<optimized out>,
vector=<optimized out>, maxdepth=<optimized out>, args_template=11782610,
nargs=<optimized out>, args=<optimized out>) at bytecode.c:785
count = 5
op = <optimized out>
vectorp = 0x932cd0
stack = {pc = 0xa52aa6 "\202I", byte_string = 9645217,
byte_string_start = 0xa52a62 "\b\211\030:\203\r",
constants = 9645253, next = 0x0}
top = 0x7fffffffc9f0
result = <optimized out>
#14 0x000000000055d53b in funcall_lambda (fun=9645157, nargs=1,
arg_vector=0x7fffffffcc38) at eval.c:3221
val = <optimized out>
syms_left = <optimized out>
next = <optimized out>
lexenv = 11782610
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
#15 0x000000000055d927 in Ffuncall (nargs=2, args=0x7fffffffcc30)
at eval.c:3039
fun = <optimized out>
original_fun = 12164530
funcar = <optimized out>
numargs = <optimized out>
lisp_numargs = <optimized out>
val = <optimized out>
backtrace = {next = 0x7fffffffce20, function = 0x7fffffffcc30,
args = 0x7fffffffcc38, nargs = 1, debug_on_exit = 0}
internal_args = <optimized out>
i = <optimized out>
#16 0x000000000055ae47 in Fcall_interactively (function=12164530,
record_flag=11782610, keys=1) at callint.c:857
val = <optimized out>
args = 0x7fffffffcc30
visargs = 0x7fffffffcc10
specs = <optimized out>
filter_specs = <optimized out>
teml = <optimized out>
up_event = 11782610
enable = 113302176
next_event = <optimized out>
prefix_arg = 11782610
string = <optimized out>
tem = <optimized out>
varies = 0x7fffffffcbf0 ""
i = <optimized out>
nargs = <optimized out>
foo = <optimized out>
prompt1 = '\000' <repeats 99 times>
tem1 = <optimized out>
arg_from_tty = <optimized out>
key_count = 1
record_then_fail = 0
save_this_command = 11782610
save_last_command = 12672082
save_this_original_command = 11782610
save_real_this_command = 11782610
#17 0x000000000055d837 in Ffuncall (nargs=4, args=0x7fffffffce90)
at eval.c:2997
fun = <optimized out>
original_fun = <optimized out>
funcar = <optimized out>
numargs = <optimized out>
lisp_numargs = <optimized out>
val = <optimized out>
backtrace = {next = 0x0, function = 0x7fffffffce90,
args = 0x7fffffffce98, nargs = 3, debug_on_exit = 0}
internal_args = 0x7fffffffce98
i = <optimized out>
#18 0x000000000055db17 in call3 (fn=<optimized out>, arg1=<optimized out>,
arg2=<optimized out>, arg3=<optimized out>) at eval.c:2790
ret_ungc_val = 14066416
args = {11988402, 12164530, 11782610, 113302181}
#19 0x00000000004f4349 in Fcommand_execute (cmd=12164530,
record_flag=11782610, keys=113302181, special=<optimized out>)
at keyboard.c:10271
final = <optimized out>
tem = <optimized out>
prefixarg = 11782610
#20 0x00000000004ff15f in read_char (commandflag=1, nmaps=6,
maps=0x7fffffffd2a0, prev_event=11782610, used_mouse_menu=0x7fffffffd41c,
end_time=0x0) at keyboard.c:2885
prev_buffer = 0x5b2eed0
c = 111001606
local_getcjmp = {{__jmpbuf = {28823509, 4398587453124662626, 11782610,
11782610, 111002422, 15938864, -4398585942129486494,
4398585288136217954}, __mask_was_saved = 0, __saved_mask = {
__val = {18446744073709551615, 4294967297, 66, 0, 0, 0, 0, 0, 0,
0, 0, 95612629, 5932106, 0, 0, 95612624}}}}
save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
__mask_was_saved = 0, __saved_mask = {__val = {
0 <repeats 16 times>}}}}
key_already_recorded = 0
tem = 12164530
save = <optimized out>
previous_echo_area_message = 11782610
also_record = 11782610
reread = 0
polling_stopped_here = 0
orig_kboard = 0xf33530
#21 0x0000000000500202 in read_key_sequence (keybuf=0x7fffffffd510,
bufsize=30, prompt=11782610, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9280
interrupted_kboard = 0xf33530
interrupted_frame = 0x121b7e0
key = <optimized out>
used_mouse_menu = 0
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
local_first_binding = 0
from_string = 11782610
count = 2
t = 0
echo_start = 0
keys_start = 0
nmaps = <optimized out>
nmaps_allocated = 6
defs = 0x7fffffffd260
submaps = 0x7fffffffd2a0
orig_local_map = 38705910
orig_keymap = 11782610
localized_local_map = 0
first_binding = 0
first_unbound = 31
mock_input = 0
fkey = {parent = 17464630, map = 17464630, start = 0, end = 0}
keytran = {parent = 11762086, map = 11762086, start = 0, end = 0}
indec = {parent = 17464614, map = 17464614, start = 0, end = 0}
shift_translated = 0
delayed_switch_frame = 11782610
original_uppercase = 0
original_uppercase_position = -1
dummyflag = 0
starting_buffer = 0x5b2eed0
fake_prefixed_keys = 11782610
#22 0x0000000000501e6a in command_loop_1 () at keyboard.c:1445
cmd = <optimized out>
keybuf = {96, 76, 0, 11782610, 11782658, 11782610, 11834802, 66165345,
140737488344496, 5738643, 7237112172834486626, -155,
140737488344496, 5738306, 11782610, 92448534, 92448534, 11782610, 0,
-1, 140737488344544, 5206430, 11782610, 11782610, 92448534, 5206735,
0, 12347184, 11782610, 0}
i = <optimized out>
prev_modiff = 3409
prev_buffer = 0x5b2eed0
#23 0x000000000055bddc in internal_condition_case (
bfun=0x501b7d <command_loop_1>, handlers=11834802,
hfun=0x4f71bf <cmd_error>) at eval.c:1491
val = <optimized out>
c = {tag = 11782610, val = 11782610, next = 0x7fffffffd7d0,
gcpro = 0x0, jmp = {{__jmpbuf = {12347184, 4398587353752950114,
12347184, 11782610, 0, -1, -4398585942355978910,
4398585508186576226}, __mask_was_saved = 0, __saved_mask = {
__val = {0, 0, 18446744073709551615, 0, 140737351956354, 1, 0,
0, 140737257920136, 0, 12347184, 12347216, 12347184,
11782610, 140737351980821, 0}}}}, backlist = 0x0,
handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
poll_suppress_count = 1, interrupt_input_blocked = 0,
byte_stack = 0x0}
h = {handler = 11834802, var = 11782610, chosen_clause = 11782658,
tag = 0x7fffffffd690, next = 0x0}
#24 0x00000000004f6951 in command_loop_2 (ignore=<optimized out>)
at keyboard.c:1156
val = 14066416
#25 0x000000000055bcb5 in internal_catch (tag=
Cannot access memory at address 0xffffffffffffffe0
) at eval.c:1248
c = {tag = 11830594, val = 11782610, next = 0x0, gcpro = 0x0, jmp = {{
__jmpbuf = {12347184, 4398587353752950114, 12347184, 11782610,
0, -1, -4398585942406310558, 4398585508193260898},
__mask_was_saved = 0, __saved_mask = {__val = {11782610,
11810656, 0, 1, 5559583, 140737261559512, 0, 0, 12075264,
12075266, 11782610, 11782610, 0, 18446744073709551615,
5632154, 140737488345352}}}}, backlist = 0x0,
handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
poll_suppress_count = 1, interrupt_input_blocked = 0,
byte_stack = 0x0}
#26 0x00000000004f6ce7 in command_loop () at keyboard.c:1135
No locals.
#27 recursive_edit_1 () at keyboard.c:756
val = 12347184
#28 0x00000000004f7017 in Frecursive_edit () at keyboard.c:820
buffer = 11782610
#29 0x00000000004f3cb5 in main (argc=<optimized out>, argv=0x7fffffffdd28)
at emacs.c:1698
dummy = 140737353841976
stack_bottom_variable = 0 '\000'
skip_args = 0
rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x100000000 <Address 0x100000000 out of bounds>
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff2466737 in kill () from /lib64/libc.so.6
A debugging session is active.
Inferior 1 [process 31722] will be killed.
Quit anyway? (y or n)
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 10:09 ` Tassilo Horn
@ 2011-09-01 10:27 ` Eli Zaretskii
2011-09-01 10:42 ` Tassilo Horn
2011-09-01 10:33 ` Andreas Schwab
1 sibling, 1 reply; 39+ messages in thread
From: Eli Zaretskii @ 2011-09-01 10:27 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
> From: Tassilo Horn <tassilo@member.fsf.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 01 Sep 2011 12:09:30 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> Hi Eli,
>
> >> From: Tassilo Horn <tassilo@member.fsf.org>
> >> Date: Wed, 31 Aug 2011 22:16:55 +0200
> >>
> >> Do you have any suggestions on how to debug this issue?
> >
> > Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
> > this happens again, tell use who called it by showing the backtrace.
>
> It turned out to be a crash, not something calling Fkill_emacs. Here's
> the backtrace:
What about the Lisp backtrace? And since this is an optimized build,
the backtrace is almost useless anyway. Can you try reproducing this
in an unoptimized build?
> #7 0x00000000004e157c in xg_display_close (dpy=0x6ca0020) at gtkutil.c:182
> gdpy = 0xd682e0
> #8 0x00000000004afc49 in x_delete_terminal (terminal=<optimized out>)
> at xterm.c:10607
> dpyinfo = 0x698d3e0
> #9 0x00000000004a40f2 in Fdelete_terminal (terminal=107998581,
> force=<optimized out>) at terminal.c:345
> t = 0x66fed70
> #10 0x00000000004235cc in delete_frame (frame=99991829, force=<optimized out>)
> at frame.c:1379
> tmp = <optimized out>
> terminal = <optimized out>
> f = 0x5f5c110
> sf = 0x121b7e0
> kb = 0x0
> minibuffer_selected = 0
> tooltip_frame = 0
> #11 0x000000000042382a in Fdelete_frame (frame=<optimized out>,
> force=<optimized out>) at frame.c:1516
This part does look as if Emacs was going to close the X display where
the frame was displayed. Were all other frames in that session on
other displays? If not, how come Emacs is about to delete the
terminal? Here's the relevant code:
if (terminal->reference_count == 0)
{
Lisp_Object tmp;
XSETTERMINAL (tmp, terminal);
kb = NULL;
Fdelete_terminal (tmp, NILP (force) ? Qt : force);
}
Can you look at the value of terminal->reference_count?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 10:09 ` Tassilo Horn
2011-09-01 10:27 ` Eli Zaretskii
@ 2011-09-01 10:33 ` Andreas Schwab
2011-09-01 10:45 ` Tassilo Horn
1 sibling, 1 reply; 39+ messages in thread
From: Andreas Schwab @ 2011-09-01 10:33 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Eli Zaretskii, emacs-devel
Tassilo Horn <tassilo@member.fsf.org> writes:
> It turned out to be a crash, not something calling Fkill_emacs. Here's
> the backtrace:
>
> Breakpoint 1 at 0x4f23dd: file emacs.c, line 1985.
> Starting program: /usr/bin/emacs-24
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7fffe6e80700 (LWP 31725)]
> [New Thread 0x7fffe667f700 (LWP 31726)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
> #0 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
> No symbol table info available.
> #1 0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
Isn't that the known gtk bug with multiple displays?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 10:27 ` Eli Zaretskii
@ 2011-09-01 10:42 ` Tassilo Horn
2011-09-01 10:56 ` Eli Zaretskii
0 siblings, 1 reply; 39+ messages in thread
From: Tassilo Horn @ 2011-09-01 10:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> It turned out to be a crash, not something calling Fkill_emacs. Here's
>> the backtrace:
>
> What about the Lisp backtrace?
That would have been xbacktrace, right? Next time...
> And since this is an optimized build, the backtrace is almost useless
> anyway. Can you try reproducing this in an unoptimized build?
That emacs was compiled with
CFLAGS="-mtune=native -O1 -pipe -g -ggdb"
and I'll try with -O0 the next time.
>> #7 0x00000000004e157c in xg_display_close (dpy=0x6ca0020) at gtkutil.c:182
>> gdpy = 0xd682e0
>> #8 0x00000000004afc49 in x_delete_terminal (terminal=<optimized out>)
>> at xterm.c:10607
>> dpyinfo = 0x698d3e0
>> #9 0x00000000004a40f2 in Fdelete_terminal (terminal=107998581,
>> force=<optimized out>) at terminal.c:345
>> t = 0x66fed70
>> #10 0x00000000004235cc in delete_frame (frame=99991829, force=<optimized out>)
>> at frame.c:1379
>> tmp = <optimized out>
>> terminal = <optimized out>
>> f = 0x5f5c110
>> sf = 0x121b7e0
>> kb = 0x0
>> minibuffer_selected = 0
>> tooltip_frame = 0
>> #11 0x000000000042382a in Fdelete_frame (frame=<optimized out>,
>> force=<optimized out>) at frame.c:1516
>
> This part does look as if Emacs was going to close the X display where
> the frame was displayed. Were all other frames in that session on
> other displays?
No, there was exactly one single frame on the current display, and no
TTY frames. Then I clicked some link to a txt file in the chromium
browser, which fired up "emacsclient -c file.txt". So then I had
exactly 2 X11 frames. Then I clicked the X knob of the frame brought up
by the client, and that made emacs crash.
> If not, how come Emacs is about to delete the terminal? Here's the
> relevant code:
>
> if (terminal->reference_count == 0)
> {
> Lisp_Object tmp;
> XSETTERMINAL (tmp, terminal);
>
> kb = NULL;
> Fdelete_terminal (tmp, NILP (force) ? Qt : force);
> }
>
> Can you look at the value of terminal->reference_count?
In an unoptimized build, that should be in the backtrace, right?
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 10:33 ` Andreas Schwab
@ 2011-09-01 10:45 ` Tassilo Horn
2011-09-01 12:47 ` Jan D.
0 siblings, 1 reply; 39+ messages in thread
From: Tassilo Horn @ 2011-09-01 10:45 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Eli Zaretskii, emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> Tassilo Horn <tassilo@member.fsf.org> writes:
>
>> It turned out to be a crash, not something calling Fkill_emacs. Here's
>> the backtrace:
>>
>> Breakpoint 1 at 0x4f23dd: file emacs.c, line 1985.
>> Starting program: /usr/bin/emacs-24
>> [Thread debugging using libthread_db enabled]
>> [New Thread 0x7fffe6e80700 (LWP 31725)]
>> [New Thread 0x7fffe667f700 (LWP 31726)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
>> #0 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
>> No symbol table info available.
>> #1 0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
>
> Isn't that the known gtk bug with multiple displays?
As said in the reply to Eli, I don't have multiple displays. There's
only one X instance in which emacs runs with exactly one X11 frame.
Then I invoked "emacsclient -c" to get another X11 frame, and closing
that made emacs crash.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 10:42 ` Tassilo Horn
@ 2011-09-01 10:56 ` Eli Zaretskii
2011-09-01 11:09 ` Tassilo Horn
0 siblings, 1 reply; 39+ messages in thread
From: Eli Zaretskii @ 2011-09-01 10:56 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
> From: Tassilo Horn <tassilo@member.fsf.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 01 Sep 2011 12:42:38 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> It turned out to be a crash, not something calling Fkill_emacs. Here's
> >> the backtrace:
> >
> > What about the Lisp backtrace?
>
> That would have been xbacktrace, right?
Yes. But if you start GDB from the src directory, xbacktrace is
automatically executed as part of backtrace.
> > This part does look as if Emacs was going to close the X display where
> > the frame was displayed. Were all other frames in that session on
> > other displays?
>
> No, there was exactly one single frame on the current display, and no
> TTY frames. Then I clicked some link to a txt file in the chromium
> browser, which fired up "emacsclient -c file.txt". So then I had
> exactly 2 X11 frames. Then I clicked the X knob of the frame brought up
> by the client, and that made emacs crash.
I think the crash is not the real problem here. The real problem here
is that Emacs "thinks" there's only one frame on that display, so it
is about to close the only display it has. Even if that doesn't
segfault, it will kill the session.
That is, if we can believe the backtrace.
Btw, if it segfaulted in all the previous times, you should be able to
see a message to that effect in your /var/log/messages (assuming this
is GNU/Linux). If you don't see there any such message, I'd very much
doubt that it segfaulted, but rather would think it indeed exited,
because the only display was closed and its terminal deleted --
exactly what we see in the backtrace you posted.
> > Can you look at the value of terminal->reference_count?
>
> In an unoptimized build, that should be in the backtrace, right?
You should be able to get to the stack frame where delete_frame calls
Fdelete_terminal (frame #10 in this case, but could be something else
next time), and print the value, yes.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 10:56 ` Eli Zaretskii
@ 2011-09-01 11:09 ` Tassilo Horn
0 siblings, 0 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-09-01 11:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
Hi Eli,
> I think the crash is not the real problem here. The real problem here
> is that Emacs "thinks" there's only one frame on that display, so it
> is about to close the only display it has.
I'm happy to announce that now I'm able to reproduce the crash. It
happens only if an emacs frame is opened for a file by the chromium web
browser.
For example, clicking "Export to BibTeX..." at
http://www.citeulike.org/bibtex_options/user/azwinkau/article/6095606
will download some *.bib text file, and because emacsclient -c is set as
default command for most text mime types, it will be invoked "somehow".
When I invoke emacsclient from a terminal, or double-click a file in
GNOME3's Nautilus, deleting that frame won't crash emacs. And neither
does "gvfs-open some-file.txt". So it seems, chromium is doing
something very special here...
Attached are some backtraces from different crashes, all with
unoptimized builds. I've produced one for each possibility to delete a
frame (X knob, C-x #, C-x 5 0).
Bye,
Tassilo
[-- Attachment #2: gdb-X-knob.txt --]
[-- Type: text/plain, Size: 12521 bytes --]
Starting program: /usr/bin/emacs-24
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6e80700 (LWP 30461)]
[New Thread 0x7fffe667f700 (LWP 30462)]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
#0 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
No symbol table info available.
#1 0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#3 0x00007ffff7599f0e in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#4 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5 0x00007ffff758c5d6 in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#6 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7 0x0000000000538909 in xg_display_close (dpy=0x47cf7c0) at gtkutil.c:182
gdpy = 0xf912e0
#8 0x000000000050a260 in x_delete_terminal (terminal=0x2861c90) at xterm.c:10607
dpyinfo = 0x13b2000
#9 0x00000000004e88a2 in Fdelete_terminal (terminal=42343573, force=12671490) at terminal.c:345
t = 0x2861c90
#10 0x00000000004271cb in delete_frame (frame=140736951987109, force=12671490) at frame.c:1379
tmp = 42343573
terminal = 0x2861c90
f = 0x7fffe007aba0
sf = 0x12f7090
kb = 0x0
minibuffer_selected = 0
tooltip_frame = 0
#11 0x0000000000427519 in Fdelete_frame (frame=140736951987109, force=12671490) at frame.c:1516
No locals.
#12 0x00000000005fe06f in Ffuncall (nargs=3, args=0x7fffffffc1a0) at eval.c:2993
fun = 9343565
original_fun = 12713650
funcar = 0
numargs = 2
lisp_numargs = 4
val = 140737488339344
backtrace = {
next = 0x7fffffffc5f0,
function = 0x7fffffffc1a0,
args = 0x7fffffffc1a8,
nargs = 2,
debug_on_exit = 0
}
internal_args = 0x7fffffffc1a8
i = 0
#13 0x0000000000649b21 in exec_byte_code (bytestr=10534465, vector=10534501, maxdepth=20,
args_template=12671442, nargs=0, args=0x0) at bytecode.c:785
count = 5
op = 2
vectorp = 0xa0be70
stack = {
pc = 0xb2bc46 "\202I",
byte_string = 10534465,
byte_string_start = 0xb2bc02 "\b\211\030:\203\r",
constants = 10534501,
next = 0x0
}
top = 0x7fffffffc1a0
result = 0
#14 0x00000000005feab3 in funcall_lambda (fun=10534405, nargs=1, arg_vector=0xa0be65) at eval.c:3221
val = 6168715
syms_left = 12671442
next = 13293682
lexenv = 12671442
count = 4
i = 1
optional = 0
rest = 0
#15 0x00000000005fe25a in Ffuncall (nargs=2, args=0x7fffffffc6d0) at eval.c:3039
fun = 10534405
original_fun = 13053362
funcar = 140737488340592
numargs = 1
lisp_numargs = 6287324
val = 140737488340592
backtrace = {
next = 0x7fffffffc9c0,
function = 0x7fffffffc6d0,
args = 0x7fffffffc6d8,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0xb7c900
i = 5642295
#16 0x00000000005f8104 in Fcall_interactively (function=13053362, record_flag=12671442, keys=72506901)
at callint.c:857
val = 0
args = 0x7fffffffc6d0
visargs = 0x7fffffffc6b0
specs = 9582913
filter_specs = 9582913
teml = 140737258374800
up_event = 12671442
enable = 12671442
speccount = 2
next_event = 1
prefix_arg = 12671442
string = 0x7fffffffc6f0 "e"
tem = 0x6b2ffc ""
varies = 0x7fffffffc690 ""
i = 2
nargs = 2
foo = 0
prompt1 = '\000' <repeats 99 times>
tem1 = 0x0
arg_from_tty = 0
gcpro1 = {
next = 0x7fffffffcae0,
var = 0x56cb4b,
nvars = 0
}
gcpro2 = {
next = 0x0,
var = 0xc159d2,
nvars = -4294967295
}
gcpro3 = {
next = 0x7fffffffcae0,
var = 0x65555c,
nvars = 2
}
gcpro4 = {
next = 0x0,
var = 0xc159d2,
nvars = 2
}
gcpro5 = {
next = 0x7fffffffc770,
var = 0x5687b7,
nvars = 140737488340832
}
key_count = 1
record_then_fail = 0
save_this_command = 12671442
save_last_command = 25642514
save_this_original_command = 12671442
save_real_this_command = 12671442
#17 0x00000000005fe09e in Ffuncall (nargs=4, args=0x7fffffffca70) at eval.c:2997
fun = 12101389
original_fun = 12877234
funcar = 0
numargs = 3
lisp_numargs = 100000000
val = 0
backtrace = {
next = 0x0,
function = 0x7fffffffca70,
args = 0x7fffffffca78,
nargs = 3,
debug_on_exit = 0
}
internal_args = 0x7fffffffca78
i = 0
#18 0x00000000005fd856 in call3 (fn=12877234, arg1=13053362, arg2=12671442, arg3=72506901) at eval.c:2790
ret_ungc_val = 12671442
gcpro1 = {
next = 0x7fffffffcab0,
var = 0xa0be05,
nvars = 4
}
args = {12877234, 13053362, 12671442, 72506901}
#19 0x0000000000573e51 in Fcommand_execute (cmd=13053362, record_flag=12671442, keys=72506901, special=12671490)
at keyboard.c:10271
final = 13053362
tem = 12671442
prefixarg = 12671442
#20 0x0000000000565342 in read_char (commandflag=1, nmaps=6, maps=0x7fffffffcf30, prev_event=12671442,
used_mouse_menu=0x7fffffffd154, end_time=0x0) at keyboard.c:2885
prev_buffer = 0x4310630
c = 63237174
jmpcount = 2
local_getcjmp = {{
__jmpbuf = {12671442, 6303929696820967229, 4286624, 140737488346352, 0, 0, 6303929696751761213,
-6303928989598435523},
__mask_was_saved = 0,
__saved_mask = {
__val = {2532, 140737488342784, 6202213, 0, 12125936, 0, 0, 0, 70321712, 0, 12705522,
140737488342528, 6730481, 12671442, 14544838, 12671442}
}
}}
save_jump = {{
__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>}
}
}}
key_already_recorded = 0
tem = 13053362
save = 12671442
previous_echo_area_message = 12671442
also_record = 12671442
reread = 0
gcpro1 = {
next = 0x7fffffffdcf0,
var = 0x0,
nvars = 12671442
}
gcpro2 = {
next = 0x1ffffcbd0,
var = 0x3c37f96,
nvars = 12705522
}
polling_stopped_here = 0
orig_kboard = 0x10092a0
#21 0x0000000000571a84 in read_key_sequence (keybuf=0x7fffffffd3c0, bufsize=30, prompt=12671442,
dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9280
interrupted_kboard = 0x10092a0
interrupted_frame = 0x7fffe007aba0
key = 70321717
used_mouse_menu = 0
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
local_first_binding = 0
from_string = 12671442
count = 2
t = 0
echo_start = 0
keys_start = 0
nmaps = 6
nmaps_allocated = 9
defs = 0x7fffffffced0
submaps = 0x7fffffffcf30
orig_local_map = 39941542
orig_keymap = 12671442
localized_local_map = 0
first_binding = 0
first_unbound = 31
mock_input = 0
fkey = {
parent = 19442342,
map = 19442342,
start = 0,
end = 0
}
keytran = {
parent = 12650918,
map = 12650918,
start = 0,
end = 0
}
indec = {
parent = 19442326,
map = 19442326,
start = 0,
end = 0
}
shift_translated = 0
delayed_switch_frame = 12671442
original_uppercase = 140737488343920
original_uppercase_position = -1
dummyflag = 0
starting_buffer = 0x4310630
fake_prefixed_keys = 12671442
outer_gcpro1 = {
next = 0x7fffffffd190,
var = 0x5e1ada,
nvars = 46480416
}
#22 0x0000000000562385 in command_loop_1 () at keyboard.c:1445
cmd = 25642514
keybuf = {460, 76, 1316582004, 12671490, 140737488344192, 6428371, 38373794, 140737488344288, 12671490,
46702790, 12698763, 0, 140737488344128, 5229317, 4294956208, 12723634, 140737488344000, 39840065, 1,
12671442, 12671442, 43719457, 140737488344192, 12671490, 140737488344256, 5643180, 140737488344288,
46702758, 4286624, 19886224}
i = 1
prev_modiff = 374
prev_buffer = 0x2c53c20
already_adjusted = 0
#23 0x00000000005fac48 in internal_condition_case (bfun=0x561f9e <command_loop_1>, handlers=12723634,
hfun=0x56189d <cmd_error>) at eval.c:1491
val = 0
c = {
tag = 12671442,
val = 12671442,
next = 0x7fffffffd710,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0, 6303929697089402685, 4286624, 140737488346352, 0, 0, 6303929697087305533,
-6303929074269112515},
__mask_was_saved = 0,
__saved_mask = {
__val = {12142814999440439101, 0, 4294967295, 5691303, 1, 9335432, 0, 0, 0, 0, 140737351956354,
1, 0, 1, 140737257920136, 0}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 12723634,
var = 12671442,
chosen_clause = 12671490,
tag = 0x7fffffffd590,
next = 0x0
}
#24 0x0000000000561c96 in command_loop_2 (ignore=12671442) at keyboard.c:1156
val = 0
#25 0x00000000005fa5d4 in internal_catch (tag=12719426, func=0x561c70 <command_loop_2>, arg=12671442)
at eval.c:1248
c = {
tag = 12719426,
val = 12671442,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {1, 6303929697175385917, 4286624, 140737488346352, 0, 0, 6303929697097791293,
-6303929074484594883},
__mask_was_saved = 0,
__saved_mask = {
__val = {6168715, 112, 4301647972, 140737261559512, 12671442, 12125984, 12699488, 14, 1,
140737488345072, 12964096, 140737488345136, 12671442, 4286624, 140737488346352,
140737488345152}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#26 0x0000000000561c49 in command_loop () at keyboard.c:1135
No locals.
#27 0x00000000005613ed in recursive_edit_1 () at keyboard.c:756
count = 1
val = 12671442
#28 0x0000000000561588 in Frecursive_edit () at keyboard.c:820
count = 0
buffer = 12671442
#29 0x000000000055f749 in main (argc=1, argv=0x7fffffffdcf8) at emacs.c:1698
dummy = 140737353921744
stack_bottom_variable = 0 '\000'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x7ffff7fc3358 "@\344\377\367\377\177"
Lisp Backtrace:
"delete-frame" (0xffffc1a8)
"handle-delete-frame" (0xffffc6d8)
"call-interactively" (0xffffca78)
"delete-frame" (0xffffc1a8)
"handle-delete-frame" (0xffffc6d8)
"call-interactively" (0xffffca78)
A debugging session is active.
Inferior 1 [process 30456] will be killed.
Quit anyway? (y or n)
[-- Attachment #3: gdb-C-#.txt --]
[-- Type: text/plain, Size: 13839 bytes --]
Starting program: /usr/bin/emacs-24
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6e80700 (LWP 30603)]
[New Thread 0x7fffe667f700 (LWP 30604)]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
#0 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
No symbol table info available.
#1 0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#3 0x00007ffff7599f0e in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#4 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5 0x00007ffff758c5d6 in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#6 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7 0x0000000000538909 in xg_display_close (dpy=0x47c9690) at gtkutil.c:182
gdpy = 0xf912e0
#8 0x000000000050a260 in x_delete_terminal (terminal=0x4b7dae0) at xterm.c:10607
dpyinfo = 0x480b400
#9 0x00000000004e88a2 in Fdelete_terminal (terminal=79157989, force=12671490) at terminal.c:345
t = 0x4b7dae0
#10 0x00000000004271cb in delete_frame (frame=44243013, force=12671442) at frame.c:1379
tmp = 79157989
terminal = 0x4b7dae0
f = 0x2a31840
sf = 0x12f7110
kb = 0x0
minibuffer_selected = 0
tooltip_frame = 0
#11 0x0000000000427519 in Fdelete_frame (frame=44243013, force=12671442) at frame.c:1516
No locals.
#12 0x00000000005fe06f in Ffuncall (nargs=2, args=0x7fffffffbb48) at eval.c:2993
fun = 9343565
original_fun = 12713650
funcar = 12671442
numargs = 1
lisp_numargs = 70368677
val = 12671442
backtrace = {
next = 0x7fffffffbfb0,
function = 0x7fffffffbb48,
args = 0x7fffffffbb50,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x7fffffffba60
i = 2
#13 0x0000000000649b21 in exec_byte_code (bytestr=30136353, vector=30613061, maxdepth=56, args_template=2052,
nargs=1, args=0x7fffffffc088) at bytecode.c:785
count = 5
op = 1
vectorp = 0x1d31e50
stack = {
pc = 0x1bcd055 "\210\001A\266\202\202o",
byte_string = 30136353,
byte_string_start = 0x1bccfc8 "\304\305\002\205\a",
constants = 30613061,
next = 0x7fffffffc0e0
}
top = 0x7fffffffbb48
result = 12671442
#14 0x00000000005fe787 in funcall_lambda (fun=29742661, nargs=1, arg_vector=0x7fffffffc080) at eval.c:3155
val = 52943670
syms_left = 2052
next = 12862258
lexenv = 12671442
count = 5
i = 3
optional = 0
rest = 0
#15 0x00000000005fe25a in Ffuncall (nargs=2, args=0x7fffffffc078) at eval.c:3039
fun = 29742661
original_fun = 31058706
funcar = 12909218
numargs = 1
lisp_numargs = 12671394
val = 12671442
backtrace = {
next = 0x7fffffffc4c0,
function = 0x7fffffffc078,
args = 0x7fffffffc080,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x7fffffffc558
i = 53123014
#16 0x0000000000649b21 in exec_byte_code (bytestr=28579745, vector=29925013, maxdepth=48, args_template=2052,
nargs=1, args=0x7fffffffc560) at bytecode.c:785
count = 5
op = 1
vectorp = 0x1c89ea0
stack = {
pc = 0x1d3b2f4 "\210\210\001A\266\202\202\003",
byte_string = 28579745,
byte_string_start = 0x1d3b290 "ʼn\b\211\203m",
constants = 29925013,
next = 0x7fffffffc5b0
}
top = 0x7fffffffc078
result = 12671442
#17 0x00000000005fe787 in funcall_lambda (fun=29925413, nargs=1, arg_vector=0x7fffffffc558) at eval.c:3155
val = 6283336
syms_left = 2052
next = 180388626432
lexenv = 140737488340112
count = 5
i = 0
optional = 0
rest = 0
#18 0x00000000005fe25a in Ffuncall (nargs=2, args=0x7fffffffc550) at eval.c:3039
fun = 29925413
original_fun = 29710274
funcar = 54089590
numargs = 1
lisp_numargs = 30383554
val = 12671442
backtrace = {
next = 0x7fffffffc990,
function = 0x7fffffffc550,
args = 0x7fffffffc558,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x7fffffffca40
i = 1
#19 0x0000000000649b21 in exec_byte_code (bytestr=28574065, vector=29925957, maxdepth=16, args_template=0,
nargs=0, args=0x7fffffffca40) at bytecode.c:785
count = 5
op = 1
vectorp = 0x1c8a250
stack = {
pc = 0x1d3b3f4 "\207",
byte_string = 28574065,
byte_string_start = 0x1d3b3c8 "\b\205,",
constants = 29925957,
next = 0x7fffffffca80
}
top = 0x7fffffffc550
result = 12671442
#20 0x00000000005fe787 in funcall_lambda (fun=29926277, nargs=0, arg_vector=0x7fffffffca40) at eval.c:3155
val = 6607736
syms_left = 0
next = 75015221
lexenv = 12671442
count = 5
i = 140737488341552
optional = -1
rest = -1
#21 0x00000000005fe25a in Ffuncall (nargs=1, args=0x7fffffffca38) at eval.c:3039
fun = 29926277
original_fun = 29710322
funcar = 44243008
numargs = 0
lisp_numargs = 44243013
val = 12906178
backtrace = {
next = 0x7fffffffce60,
function = 0x7fffffffca38,
args = 0x7fffffffca40,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x7fffffffcf48
i = 12671442
#22 0x0000000000649b21 in exec_byte_code (bytestr=28557265, vector=29927637, maxdepth=16, args_template=1024,
nargs=1, args=0x7fffffffcf50) at bytecode.c:785
count = 5
op = 0
vectorp = 0x1c8a8e0
stack = {
pc = 0x1d3b564 "\"\207\311\312!\207",
byte_string = 28557265,
byte_string_start = 0x1d3b548 "\211\204\020",
constants = 29927637,
next = 0x0
}
top = 0x7fffffffca38
result = 42799397
#23 0x00000000005fe787 in funcall_lambda (fun=29927957, nargs=1, arg_vector=0x7fffffffcf48) at eval.c:3155
val = 6168715
syms_left = 1024
next = 12671394
lexenv = 12671442
count = 5
i = 8589921872
optional = 0
rest = 5705370
#24 0x00000000005fe25a in Ffuncall (nargs=2, args=0x7fffffffcf40) at eval.c:3039
fun = 29927957
original_fun = 29710370
funcar = 140737488342752
numargs = 1
lisp_numargs = 6287324
val = 140737488342752
backtrace = {
next = 0x7fffffffd230,
function = 0x7fffffffcf40,
args = 0x7fffffffcf48,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x1d3b5a0
i = 5642295
#25 0x00000000005f8104 in Fcall_interactively (function=29710370, record_flag=12671442, keys=12717765)
at callint.c:857
val = 0
args = 0x7fffffffcf40
visargs = 0x7fffffffcf20
specs = 28556033
filter_specs = 28556033
teml = 0
up_event = 12671442
enable = 12671442
speccount = 3
next_event = 2
prefix_arg = 12671442
string = 0x7fffffffcf60 "P"
tem = 0x6b2ffc ""
varies = 0x7fffffffcf00 ""
i = 2
nargs = 2
foo = 0
prompt1 = '\000' <repeats 99 times>
tem1 = 0x0
arg_from_tty = 0
gcpro1 = {
next = 0x7fffffffd090,
var = 0x7ffff24cc5da,
nvars = 140737488343120
}
gcpro2 = {
next = 0x7fffffffd020,
var = 0x7ffff7ffb8ad,
nvars = 140737488343760
}
gcpro3 = {
next = 0xc159d2,
var = 0x7ffff7ffb639,
nvars = 2
}
gcpro4 = {
next = 0x1c55822,
var = 0x12773c2,
nvars = 2
}
gcpro5 = {
next = 0x7fffffffd020,
var = 0x5feac8,
nvars = 0
}
key_count = 2
record_then_fail = 0
save_this_command = 29710370
save_last_command = 36428754
save_this_original_command = 29710370
save_real_this_command = 29710370
#26 0x00000000005fe09e in Ffuncall (nargs=4, args=0x7fffffffd2e0) at eval.c:2997
fun = 12101389
original_fun = 12877234
funcar = 0
numargs = 3
lisp_numargs = 0
val = 0
backtrace = {
next = 0x0,
function = 0x7fffffffd2e0,
args = 0x7fffffffd2e8,
nargs = 3,
debug_on_exit = 0
}
internal_args = 0x7fffffffd2e8
i = 0
#27 0x00000000005fd856 in call3 (fn=12877234, arg1=29710370, arg2=12671442, arg3=12671442) at eval.c:2790
ret_ungc_val = 12671442
gcpro1 = {
next = 0x7fffffffd320,
var = 0x1c8aa15,
nvars = 4
}
args = {12877234, 29710370, 12671442, 12671442}
#28 0x0000000000573e51 in Fcommand_execute (cmd=29710370, record_flag=12671442, keys=12671442, special=12671442)
at keyboard.c:10271
final = 29710370
tem = 12671442
prefixarg = 12671442
#29 0x0000000000562844 in command_loop_1 () at keyboard.c:1572
scount = 2
cmd = 29710370
keybuf = {96, 140, 4286624, 140737488346352, 140737488344080, 6167415, 140737488344160, 12671442,
276967387, 1, 140737488344160, 6169746, 12671442, 12859474, 140737488344240, 6168715, 12507328,
8589923456, 0, 12859472, 140737488344320, 6287904, 12981974, 8589934593, 12859474, 12671442, 0, 0,
4286624, 140737488346352}
i = 2
prev_modiff = 27
prev_buffer = 0x478a430
already_adjusted = 0
#30 0x00000000005fac48 in internal_condition_case (bfun=0x561f9e <command_loop_1>, handlers=12723634,
hfun=0x56189d <cmd_error>) at eval.c:1491
val = 0
c = {
tag = 12671442,
val = 12671442,
next = 0x7fffffffd710,
gcpro = 0x0,
jmp = {{
__jmpbuf = {1, -5948150678907524226, 4286624, 140737488346352, 0, 0, -5948150678813152386,
5948150339555683198},
__mask_was_saved = 0,
__saved_mask = {
__val = {5948150339555683198, 0, 4294967295, 5691303, 1, 9335432, 0, 0, 0, 0, 140737351956354,
1, 0, 1, 140737257920136, 0}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 12723634,
var = 12671442,
chosen_clause = 12723634,
tag = 0x7fffffffd590,
next = 0x0
}
#31 0x0000000000561c96 in command_loop_2 (ignore=12671442) at keyboard.c:1156
val = 1
#32 0x00000000005fa5d4 in internal_catch (tag=12719426, func=0x561c70 <command_loop_2>, arg=12671442)
at eval.c:1248
c = {
tag = 12719426,
val = 12671442,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {1, -5948150678456636546, 4286624, 140737488346352, 0, 0, -5948150678899135618,
5948150339209128830},
__mask_was_saved = 0,
__saved_mask = {
__val = {6168715, 112, 4301647972, 140737261559512, 12671442, 12125984, 12699488, 14, 1,
140737488345072, 12964096, 140737488345136, 12671442, 4286624, 140737488346352,
140737488345152}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#33 0x0000000000561c49 in command_loop () at keyboard.c:1135
No locals.
#34 0x00000000005613ed in recursive_edit_1 () at keyboard.c:756
count = 1
val = 12671442
#35 0x0000000000561588 in Frecursive_edit () at keyboard.c:820
count = 0
buffer = 12671442
#36 0x000000000055f749 in main (argc=1, argv=0x7fffffffdcf8) at emacs.c:1698
dummy = 140737353921744
stack_bottom_variable = 0 '\000'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x7ffff7fc3358 "@\344\377\367\377\177"
Lisp Backtrace:
"delete-frame" (0xffffbb50)
"server-delete-client" (0xffffc080)
"server-buffer-done" (0xffffc558)
"server-done" (0xffffca40)
"server-edit" (0xffffcf48)
"call-interactively" (0xffffd2e8)
A debugging session is active.
Inferior 1 [process 30598] will be killed.
Quit anyway? (y or n)
[-- Attachment #4: gdb-C-x-5-0.txt --]
[-- Type: text/plain, Size: 8459 bytes --]
Starting program: /usr/bin/emacs-24
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6e80700 (LWP 30710)]
[New Thread 0x7fffe667f700 (LWP 30711)]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
#0 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
No symbol table info available.
#1 0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#3 0x00007ffff7599f0e in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#4 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5 0x00007ffff758c5d6 in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#6 0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7 0x0000000000538909 in xg_display_close (dpy=0x2a339b0) at gtkutil.c:182
gdpy = 0xf912e0
#8 0x000000000050a260 in x_delete_terminal (terminal=0x2a45400) at xterm.c:10607
dpyinfo = 0x2a47400
#9 0x00000000004e88a2 in Fdelete_terminal (terminal=44323845, force=12671490) at terminal.c:345
t = 0x2a45400
#10 0x00000000004271cb in delete_frame (frame=44346293, force=12671442) at frame.c:1379
tmp = 44323845
terminal = 0x2a45400
f = 0x2a4abb0
sf = 0x1311e90
kb = 0x0
minibuffer_selected = 0
tooltip_frame = 0
#11 0x0000000000427519 in Fdelete_frame (frame=12671442, force=12671442) at frame.c:1516
No locals.
#12 0x00000000005fe06f in Ffuncall (nargs=1, args=0x7fffffffcf50) at eval.c:2993
fun = 9343565
original_fun = 12713650
funcar = 140737488342784
numargs = 0
lisp_numargs = 6287324
val = 9379585
backtrace = {
next = 0x7fffffffd230,
function = 0x7fffffffcf50,
args = 0x7fffffffcf58,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x7fffffffce50
i = 2
#13 0x00000000005f8104 in Fcall_interactively (function=12713650, record_flag=12671442, keys=12717765)
at callint.c:857
val = 0
args = 0x7fffffffcf50
visargs = 0x7fffffffcf30
specs = 9379585
filter_specs = 9379585
teml = 0
up_event = 12671442
enable = 12671442
speccount = 3
next_event = 3
prefix_arg = 12671442
string = 0x7fffffffcf70 ""
tem = 0x7fffffffcf70 ""
varies = 0x7fffffffcf20 ""
i = 1
nargs = 1
foo = 0
prompt1 = '\000' <repeats 24 times>, "<B\017", '\000' <repeats 13 times>, "<B\017\000\000\000\000\000\301d_N\000\000\000\000\372\323\n\000\000\000\000\000\320\322\377\377\377\177\000\000\320\322\377\377\377\177\000\000p\323\377\377\377\177\000\000\276\063f\000\000\000\000\000\000 \000"
tem1 = 0x0
arg_from_tty = 0
gcpro1 = {
next = 0x7fffffffd090,
var = 0x7ffff24cc5da,
nvars = 140737488343120
}
gcpro2 = {
next = 0x7fffffffd020,
var = 0x7ffff7ffb8ad,
nvars = 140737488343760
}
gcpro3 = {
next = 0xc159d2,
var = 0x7ffff7ffb639,
nvars = 1
}
gcpro4 = {
next = 0xc1feb2,
var = 0x12773c2,
nvars = 1
}
gcpro5 = {
next = 0x7fffffffd020,
var = 0x5feac8,
nvars = 0
}
key_count = 3
record_then_fail = 0
save_this_command = 12713650
save_last_command = 19208866
save_this_original_command = 12713650
save_real_this_command = 12713650
#14 0x00000000005fe09e in Ffuncall (nargs=4, args=0x7fffffffd2e0) at eval.c:2997
fun = 12101389
original_fun = 12877234
funcar = 0
numargs = 3
lisp_numargs = 0
val = 0
backtrace = {
next = 0x0,
function = 0x7fffffffd2e0,
args = 0x7fffffffd2e8,
nargs = 3,
debug_on_exit = 0
}
internal_args = 0x7fffffffd2e8
i = 0
#15 0x00000000005fd856 in call3 (fn=12877234, arg1=12713650, arg2=12671442, arg3=12671442) at eval.c:2790
ret_ungc_val = 12671442
gcpro1 = {
next = 0x7fffffffd320,
var = 0x8e924d,
nvars = 4
}
args = {12877234, 12713650, 12671442, 12671442}
#16 0x0000000000573e51 in Fcommand_execute (cmd=12713650, record_flag=12671442, keys=12671442, special=12671442)
at keyboard.c:10271
final = 12713650
tem = 12671442
prefixarg = 12671442
#17 0x0000000000562844 in command_loop_1 () at keyboard.c:1572
scount = 2
cmd = 12713650
keybuf = {96, 212, 192, 140737488346352, 140737488344080, 6167415, 140737488344160, 12671442, 276967387,
1, 140737488344160, 6169746, 12671442, 12859474, 140737488344240, 6168715, 12507328, 8589923456, 0,
12859472, 140737488344320, 6287904, 12981974, 8589934593, 12859474, 12671442, 0, 0, 4286624,
140737488346352}
i = 3
prev_modiff = 27
prev_buffer = 0x2ebf030
already_adjusted = 0
#18 0x00000000005fac48 in internal_condition_case (bfun=0x561f9e <command_loop_1>, handlers=12723634,
hfun=0x56189d <cmd_error>) at eval.c:1491
val = 0
c = {
tag = 12671442,
val = 12671442,
next = 0x7fffffffd710,
gcpro = 0x0,
jmp = {{
__jmpbuf = {1, 5498248946679664099, 4286624, 140737488346352, 0, 0, 5498248946761453027,
-5498249689761067549},
__mask_was_saved = 0,
__saved_mask = {
__val = {12948494383948484067, 0, 4294967295, 5691303, 1, 9335432, 0, 0, 0, 0, 140737351956354,
1, 0, 1, 140737257920136, 0}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 12723634,
var = 12671442,
chosen_clause = 12723634,
tag = 0x7fffffffd590,
next = 0x0
}
#19 0x0000000000561c96 in command_loop_2 (ignore=12671442) at keyboard.c:1156
val = 1
#20 0x00000000005fa5d4 in internal_catch (tag=12719426, func=0x561c70 <command_loop_2>, arg=12671442)
at eval.c:1248
c = {
tag = 12719426,
val = 12671442,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {1, 5498248946329439715, 4286624, 140737488346352, 0, 0, 5498248946671275491,
-5498249689287635485},
__mask_was_saved = 0,
__saved_mask = {
__val = {6168715, 112, 4301647972, 140737261559512, 12671442, 12125984, 12699488, 14, 1,
140737488345072, 12964096, 140737488345136, 12671442, 4286624, 140737488346352,
140737488345152}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#21 0x0000000000561c49 in command_loop () at keyboard.c:1135
No locals.
#22 0x00000000005613ed in recursive_edit_1 () at keyboard.c:756
count = 1
val = 12671442
#23 0x0000000000561588 in Frecursive_edit () at keyboard.c:820
count = 0
buffer = 12671442
#24 0x000000000055f749 in main (argc=1, argv=0x7fffffffdcf8) at emacs.c:1698
dummy = 140737353921744
stack_bottom_variable = 0 '\000'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x7ffff7fc3358 "@\344\377\367\377\177"
Lisp Backtrace:
"delete-frame" (0xffffcf58)
"call-interactively" (0xffffd2e8)
A debugging session is active.
Inferior 1 [process 30705] will be killed.
Quit anyway? (y or n)
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 10:45 ` Tassilo Horn
@ 2011-09-01 12:47 ` Jan D.
2011-09-01 13:05 ` Tassilo Horn
2011-09-01 15:29 ` Eli Zaretskii
0 siblings, 2 replies; 39+ messages in thread
From: Jan D. @ 2011-09-01 12:47 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Eli Zaretskii, Andreas Schwab, emacs-devel
Tassilo Horn skrev 2011-09-01 12:45:
> Andreas Schwab<schwab@linux-m68k.org> writes:
>
>> Isn't that the known gtk bug with multiple displays?
>
> As said in the reply to Eli, I don't have multiple displays. There's
> only one X instance in which emacs runs with exactly one X11 frame.
> Then I invoked "emacsclient -c" to get another X11 frame, and closing
> that made emacs crash.
From Emacs point of view, localhost:0 and unix:0 and :0 are three
different displays, even if they physically are the same.
Try doing the same and after you clicked the link in chromium, evaluate
(x-display-list). If you have more than one entry, it is the Gtk+ problem.
Jan D.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 12:47 ` Jan D.
@ 2011-09-01 13:05 ` Tassilo Horn
2011-09-01 15:29 ` Eli Zaretskii
1 sibling, 0 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-09-01 13:05 UTC (permalink / raw)
To: Jan D.; +Cc: Eli Zaretskii, Andreas Schwab, emacs-devel
"Jan D." <jan.h.d@swipnet.se> writes:
>>> Isn't that the known gtk bug with multiple displays?
>>
>> As said in the reply to Eli, I don't have multiple displays. There's
>> only one X instance in which emacs runs with exactly one X11 frame.
>> Then I invoked "emacsclient -c" to get another X11 frame, and closing
>> that made emacs crash.
>
> From Emacs point of view, localhost:0 and unix:0 and :0 are three
> different displays, even if they physically are the same.
>
> Try doing the same and after you clicked the link in chromium, evaluate
> (x-display-list). If you have more than one entry, it is the Gtk+ problem.
Indeed, after opening a new emacs frame from chromium, I have two
entries: (":0.0" ":0"). Before that, it was only (":0.0").
But still, since all other apps somehow spawning new emacs frames don't
create this problem, I wonder if chromium does something special. I've
checked its sources, and eventually it'll call something like
XDGUtil("xdg-open", "path/to/file.txt");
You can check that function here:
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/chrome/browser/platform_util_linux.cc&l=17
That in turn calls LaunchProcess()
http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/base/process_util_posix.cc&l=531
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 12:47 ` Jan D.
2011-09-01 13:05 ` Tassilo Horn
@ 2011-09-01 15:29 ` Eli Zaretskii
2011-09-01 19:30 ` Ken Raeburn
2011-10-11 6:46 ` Tassilo Horn
1 sibling, 2 replies; 39+ messages in thread
From: Eli Zaretskii @ 2011-09-01 15:29 UTC (permalink / raw)
To: Jan D.; +Cc: tassilo, schwab, emacs-devel
> Date: Thu, 01 Sep 2011 14:47:09 +0200
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: Andreas Schwab <schwab@linux-m68k.org>, Eli Zaretskii <eliz@gnu.org>,
> emacs-devel@gnu.org
>
> From Emacs point of view, localhost:0 and unix:0 and :0 are three
> different displays, even if they physically are the same.
Can't we do something in Emacs so it understood that they are on the
same display? That won't fix the GTK problem, but at least it will
work around it in this particular use case. And I think it's a Good
Thing in general, no?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 15:29 ` Eli Zaretskii
@ 2011-09-01 19:30 ` Ken Raeburn
2011-09-02 15:02 ` Andreas Schwab
2011-10-11 6:46 ` Tassilo Horn
1 sibling, 1 reply; 39+ messages in thread
From: Ken Raeburn @ 2011-09-01 19:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Emacs Dev
On Sep 1, 2011, at 11:29, Eli Zaretskii wrote:
>> Date: Thu, 01 Sep 2011 14:47:09 +0200
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: Andreas Schwab <schwab@linux-m68k.org>, Eli Zaretskii <eliz@gnu.org>,
>> emacs-devel@gnu.org
>>
>> From Emacs point of view, localhost:0 and unix:0 and :0 are three
>> different displays, even if they physically are the same.
>
> Can't we do something in Emacs so it understood that they are on the
> same display? That won't fix the GTK problem, but at least it will
> work around it in this particular use case. And I think it's a Good
> Thing in general, no?
>
If that's the intent of the X code... I've actually seen cases where the hostname "unix" gets looked up, so maybe the rule is "unix means the local host if you don't have a machine named unix". I'm not sure if that was X11 software or something else trying to interpret $DISPLAY, though; I was looking at DNS packet traces.
In this case, ":0.0" vs ":0" is even more straightforward. According to the X man page I just looked up, at least, the default screen number is zero if omitted (not some changeable per-display default screen number), so counting those two as the same should be easy.
Ken
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 19:30 ` Ken Raeburn
@ 2011-09-02 15:02 ` Andreas Schwab
0 siblings, 0 replies; 39+ messages in thread
From: Andreas Schwab @ 2011-09-02 15:02 UTC (permalink / raw)
To: Ken Raeburn; +Cc: Eli Zaretskii, Emacs Dev
Ken Raeburn <raeburn@raeburn.org> writes:
> If that's the intent of the X code... I've actually seen cases where the
> hostname "unix" gets looked up, so maybe the rule is "unix means the local
> host if you don't have a machine named unix".
At least libxcb (the X transport layer) recognizes unix:N specially.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-09-01 15:29 ` Eli Zaretskii
2011-09-01 19:30 ` Ken Raeburn
@ 2011-10-11 6:46 ` Tassilo Horn
2011-10-11 12:53 ` Stefan Monnier
2011-10-11 17:56 ` Jan Djärv
1 sibling, 2 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-10-11 6:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Jan D., schwab, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Thu, 01 Sep 2011 14:47:09 +0200
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: Andreas Schwab <schwab@linux-m68k.org>, Eli Zaretskii <eliz@gnu.org>,
>> emacs-devel@gnu.org
>>
>> From Emacs point of view, localhost:0 and unix:0 and :0 are three
>> different displays, even if they physically are the same.
>
> Can't we do something in Emacs so it understood that they are on the
> same display? That won't fix the GTK problem, but at least it will
> work around it in this particular use case. And I think it's a Good
> Thing in general, no?
Any news on that front? I'm still accidentally killing emacs at least
twice a day. And I'm already trying hard not to fire up an emacsclient
X11 frame form external GTK apps, which is really really annoying. For
example, when I click on a textfile link in a browser, I have to be sure
to save it and then open it from inside emacs, instead of simply letting
the browser invoke emacsclient after which I would have a frame that
would kill emacs when being deleted...
With resepect to the Emacs 24 release, it's very likely that a lot of
users will suffer from this issue, so although it's a gtk bug, there
should be some workaround (probably enabled by default).
For me and I guess for most users, localhost:0, unix:0 (*), :0.0, and :0
are all the same in practice, only localhost:1 or :2 actually mean other
displays. So I'd simply strip localhost and unix before the colon and
dot-zeros. (Maybe there should be an option for that, or some lisp
function that would be called to transform the display name if it is
defined...)
Bye,
Tassilo
(*) I'm not too sure with unix:0. I know such an entry only from
xorg.conf to tell the xserver where the font server is running.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-11 6:46 ` Tassilo Horn
@ 2011-10-11 12:53 ` Stefan Monnier
2011-10-11 14:53 ` Tassilo Horn
2011-10-11 17:56 ` Jan Djärv
1 sibling, 1 reply; 39+ messages in thread
From: Stefan Monnier @ 2011-10-11 12:53 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Eli Zaretskii, Jan D., schwab, emacs-devel
> With resepect to the Emacs 24 release, it's very likely that a lot of
> users will suffer from this issue, so although it's a gtk bug, there
> should be some workaround (probably enabled by default).
I can't imagine why "a lot of users" would run Emacs with different (but
equivalent) values of $DISPLAY.
Stefan
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-11 12:53 ` Stefan Monnier
@ 2011-10-11 14:53 ` Tassilo Horn
2011-10-11 17:38 ` James Cloos
0 siblings, 1 reply; 39+ messages in thread
From: Tassilo Horn @ 2011-10-11 14:53 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, Jan D., schwab, Ulrich Mueller, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
Hi Stefan,
>> With resepect to the Emacs 24 release, it's very likely that a lot of
>> users will suffer from this issue, so although it's a gtk bug, there
>> should be some workaround (probably enabled by default).
>
> I can't imagine why "a lot of users" would run Emacs with different
> (but equivalent) values of $DISPLAY.
They don't do that intentionally, it's a bug in GTK:
https://bugzilla.gnome.org/show_bug.cgi?id=85715#c55
[Ulrich, I added you to Cc because you commented on the report above, so
you probably know a bit better about what's going wrong there.]
The problem in my usecase is that when I fire up emacs or emacsclient -c
from the GNOME3 application menu or the run command dialog, it says it
is on DISPLAY :0, i.e., (x-display-list) returns (":0").
In contrast, when I start emacs or emacsclient -c from a GNOME terminal
or the file manager or web browser fire up an emacsclient -c, because
I've set that up as default application for text files, the DISPLAY is
:0.0.
So as soon as I mix these two invocation styles, (x-display-list)
returns (":0" ":0.0"). Those displays are different, and when I delete
the last frame on one of the (equivalent) displays, emacs (including the
original frames on the other displays) are killed.
Not sure who kills emacs. Reading the bug report above, it seems that
GTK deletes the display, and then emacs crashes because its display is
gone.
Maybe a workaround could be to initially tell GTK that emacs runs on
both :0 and :0.0, so that GTK never thinks the last frame is going to be
deleted.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-11 14:53 ` Tassilo Horn
@ 2011-10-11 17:38 ` James Cloos
2011-10-11 19:17 ` Tassilo Horn
2011-10-12 2:04 ` Chong Yidong
0 siblings, 2 replies; 39+ messages in thread
From: James Cloos @ 2011-10-11 17:38 UTC (permalink / raw)
To: Tassilo Horn
Cc: Ulrich Mueller, emacs-devel, schwab, Stefan Monnier,
Eli Zaretskii, Jan D.
>>>>> "TH" == Tassilo Horn <tassilo@member.fsf.org> writes:
TH> So as soon as I mix these two invocation styles, (x-display-list)
TH> returns (":0" ":0.0"). Those displays are different, and when I
TH> delete the last frame on one of the (equivalent) displays, emacs
TH> (including the original frames on the other displays) are killed.
It seems, then, that emacs needs to canonicalize the DISPLAY strings
before comparing them.
I thought that I remembered some some code in libX11 and/or xtrans
which does that, but a quick grep(1) did not illuminate any.
(Apologies for the pun. Err, was that another one?)
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-11 6:46 ` Tassilo Horn
2011-10-11 12:53 ` Stefan Monnier
@ 2011-10-11 17:56 ` Jan Djärv
1 sibling, 0 replies; 39+ messages in thread
From: Jan Djärv @ 2011-10-11 17:56 UTC (permalink / raw)
To: Tassilo Horn; +Cc: Eli Zaretskii, schwab, emacs-devel
Tassilo Horn skrev 2011-10-11 08:46:
> For me and I guess for most users, localhost:0, unix:0 (*), :0.0, and :0
> are all the same in practice, only localhost:1 or :2 actually mean other
> displays. So I'd simply strip localhost and unix before the colon and
> dot-zeros. (Maybe there should be an option for that, or some lisp
> function that would be called to transform the display name if it is
> defined...)
>
It is probably better to use some heruistics to see if two displays are really
the same. If the root window id and the default visual id are the same, they
probably are the same display. You can throw in protocol version, vendor
string, screen dimension checks also.
Jan D.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-11 17:38 ` James Cloos
@ 2011-10-11 19:17 ` Tassilo Horn
2011-10-11 19:49 ` Tassilo Horn
2011-10-12 2:04 ` Chong Yidong
1 sibling, 1 reply; 39+ messages in thread
From: Tassilo Horn @ 2011-10-11 19:17 UTC (permalink / raw)
To: James Cloos
Cc: Ulrich Mueller, emacs-devel, schwab, Stefan Monnier,
Eli Zaretskii, Jan D.
James Cloos <cloos@jhcloos.com> writes:
> TH> So as soon as I mix these two invocation styles, (x-display-list)
> TH> returns (":0" ":0.0"). Those displays are different, and when I
> TH> delete the last frame on one of the (equivalent) displays, emacs
> TH> (including the original frames on the other displays) are killed.
>
> It seems, then, that emacs needs to canonicalize the DISPLAY strings
> before comparing them.
It's not that emacs kills itself. It segfaults probably because gtk
deletes/frees the display while emacs is still using it. (Well, or
something like that...)
Oh, checking the backtrace I've posted at the beginning of this thread,
I've found this code in gtkutil.c:
--8<---------------cut here---------------start------------->8---
#if GTK_MAJOR_VERSION == 2 && GTK_MINOR_VERSION < 10
/* GTK 2.2-2.8 has a bug that makes gdk_display_close crash (bug
http://bugzilla.gnome.org/show_bug.cgi?id=85715). This way we
can continue running, but there will be memory leaks. */
g_object_run_dispose (G_OBJECT (gdpy));
#else
/* This seems to be fixed in GTK 2.10. */
gdk_display_close (gdpy);
#endif
}
--8<---------------cut here---------------end--------------->8---
That's already the right workaround, isn't it? The only thing is that
this bug is *not* fixed in GTK 2.10 but instead still exists (or exists
again) in GTK 3.2.0.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-11 19:17 ` Tassilo Horn
@ 2011-10-11 19:49 ` Tassilo Horn
0 siblings, 0 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-10-11 19:49 UTC (permalink / raw)
To: James Cloos
Cc: Ulrich Mueller, emacs-devel, schwab, Stefan Monnier,
Eli Zaretskii, Jan D.
Tassilo Horn <tassilo@member.fsf.org> writes:
> Oh, checking the backtrace I've posted at the beginning of this thread,
> I've found this code in gtkutil.c:
>
> #if GTK_MAJOR_VERSION == 2 && GTK_MINOR_VERSION < 10
> /* GTK 2.2-2.8 has a bug that makes gdk_display_close crash (bug
> http://bugzilla.gnome.org/show_bug.cgi?id=85715). This way we
> can continue running, but there will be memory leaks. */
> g_object_run_dispose (G_OBJECT (gdpy));
> #else
> /* This seems to be fixed in GTK 2.10. */
> gdk_display_close (gdpy);
> #endif
> }
>
> That's already the right workaround, isn't it? The only thing is that
> this bug is *not* fixed in GTK 2.10 but instead still exists (or
> exists again) in GTK 3.2.0.
I've just commented the line in the #else and recompiled emacs and
reproduced the issue, i.e., started emacs using the application menu
(resulting in a frame on display :0) and then opened another frame using
emacsclient -c in a gnome terminal, so that in the end (x-display-list)
returned (":0" ":0.0").
Then I deleted the frame created by emacsclient -c using C-x 5 0. The
result is that the frame is still there but not functional. I can't
even see the mouse pointer when hovering over it. From my perspective,
that's an improvement. :-)
(x-display-list) returns (":0") again.
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-11 17:38 ` James Cloos
2011-10-11 19:17 ` Tassilo Horn
@ 2011-10-12 2:04 ` Chong Yidong
2011-10-12 6:49 ` Tassilo Horn
1 sibling, 1 reply; 39+ messages in thread
From: Chong Yidong @ 2011-10-12 2:04 UTC (permalink / raw)
To: James Cloos
Cc: Ulrich Mueller, emacs-devel, schwab, Stefan Monnier, Tassilo Horn,
Jan D., Eli Zaretskii
James Cloos <cloos@jhcloos.com> writes:
> It seems, then, that emacs needs to canonicalize the DISPLAY strings
> before comparing them.
>
> I thought that I remembered some some code in libX11 and/or xtrans
> which does that, but a quick grep(1) did not illuminate any.
I'm not sure that can be made to work reliably.
Perhaps what we should do, instead, is to avoid deleting terminals in
delete_frame if Emacs is compiled with GTK. The original intention was
for Emacs to close remote X connections when we're done with them. But
if GTK responds to an X connection closing by crashing, maybe we should
just not close those X connections at all.
Tassilo, could you experiment with commenting out the terminal deletion
code in frame.c:1362, and see what the behavior is like?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-12 2:04 ` Chong Yidong
@ 2011-10-12 6:49 ` Tassilo Horn
2011-10-12 12:57 ` Stefan Monnier
0 siblings, 1 reply; 39+ messages in thread
From: Tassilo Horn @ 2011-10-12 6:49 UTC (permalink / raw)
To: Chong Yidong
Cc: Ulrich Mueller, emacs-devel, schwab, Stefan Monnier, James Cloos,
Eli Zaretskii, Jan D.
Chong Yidong <cyd@stupidchicken.com> writes:
> James Cloos <cloos@jhcloos.com> writes:
>
>> It seems, then, that emacs needs to canonicalize the DISPLAY strings
>> before comparing them.
>>
>> I thought that I remembered some some code in libX11 and/or xtrans
>> which does that, but a quick grep(1) did not illuminate any.
>
> I'm not sure that can be made to work reliably.
>
> Perhaps what we should do, instead, is to avoid deleting terminals in
> delete_frame if Emacs is compiled with GTK. The original intention was
> for Emacs to close remote X connections when we're done with them. But
> if GTK responds to an X connection closing by crashing, maybe we should
> just not close those X connections at all.
>
> Tassilo, could you experiment with commenting out the terminal deletion
> code in frame.c:1362, and see what the behavior is like?
I commente 3 lines as indicated below:
--8<---------------cut here---------------start------------->8---
/* If needed, delete the terminal that this frame was on.
(This must be done after the frame is killed.) */
terminal->reference_count--;
if (terminal->reference_count == 0)
{
// Lisp_Object tmp;
// XSETTERMINAL (tmp, terminal);
kb = NULL;
// Fdelete_terminal (tmp, NILP (force) ? Qt : force);
}
else
kb = terminal->kboard;
--8<---------------cut here---------------end--------------->8---
I'm not sure if keeping the "kb = NULL;" was correct, though. If you
want, I can try again with the complete then block commented.
Ok, at first, it seemed to work fine. I could create and delete frames
without crashing emacs, although (x-display-list) returned (":0"
":0.0"). However, after the n-th cycle in my create/delete random
frames test, emacs eventually crashed. This is the backtrace:
--8<---------------cut here---------------start------------->8---
% gdb /usr/bin/emacs-24
GNU gdb (Gentoo 7.3.1 p1) 7.3.1
Copyright (C) 2011 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 "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/bin/emacs-24...done.
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.0
TERM = xterm-256color
Breakpoint 1 at 0x55eebb: file emacs.c, line 386.
Temporary breakpoint 2 at 0x5831a4: file sysdep.c, line 858.
(gdb) run
Starting program: /usr/bin/emacs-24
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6b98700 (LWP 1695)]
[New Thread 0x7fffe6396700 (LWP 1696)]
(emacs-24:1692): Gtk-CRITICAL **: gtk_style_context_get: assertion `priv->widget_path != NULL' failed
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6ce6fa5 in cairo_pattern_reference () from /usr/lib64/libcairo.so.2
(gdb) bt full
#0 0x00007ffff6ce6fa5 in cairo_pattern_reference ()
from /usr/lib64/libcairo.so.2
No symbol table info available.
#1 0x00007ffff75364bb in gdk_window_set_background_pattern ()
from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2 0x00007ffff795f600 in gtk_style_context_set_background ()
from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#3 0x00007ffff7a1fb4d in ?? () from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#4 0x00007ffff65656a5 in g_closure_invoke ()
from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5 0x00007ffff65775b2 in ?? () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#6 0x00007ffff65810b4 in g_signal_emit_valist ()
from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7 0x00007ffff6581243 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#8 0x00007ffff7a1aaa2 in ?? () from /usr/lib64/libgtk-3.so.0
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#9 0x00007ffff65656a5 in g_closure_invoke ()
from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#10 0x00007ffff6577dc1 in ?? () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#11 0x00007ffff65810b4 in g_signal_emit_valist ()
from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#12 0x00007ffff6581243 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#13 0x00007ffff795f081 in gtk_style_context_invalidate ()
from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#14 0x00007ffff7a1f1e7 in gtk_widget_get_style_context ()
from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#15 0x00007ffff789b497 in ?? () from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#16 0x00007ffff65656a5 in g_closure_invoke ()
from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#17 0x00007ffff65775b2 in ?? () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#18 0x00007ffff65810b4 in g_signal_emit_valist ()
from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#19 0x00007ffff6581243 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#20 0x00007ffff7a1cd18 in gtk_widget_realize () from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#21 0x000000000053beac in xg_create_frame_widgets (f=0x27852d0)
at gtkutil.c:1186
wtop = 0x15fd730
wvbox = 0x12d70c0
whbox = 0x1615a70
wfixed = 0x12d7df0
title = 0x12e4200 "emacs-24@thinkpad.tsdh.de"
#22 0x0000000000510454 in x_window (f=0x27852d0) at xfns.c:2612
No locals.
#23 0x0000000000512259 in Fx_create_frame (parms=40860694) at xfns.c:3359
f = 0x27852d0
frame = 41439957
tem = 12741026
name = 12741026
minibuffer_only = 0
window_prompting = 0
---Type <return> to continue, or q <return> to quit---
width = 0
height = 12741074
count = 20
gcpro1 = {
next = 0xc269d2,
var = 0x5daca4,
nvars = 140737488323976
}
gcpro2 = {
next = 0x29b2ff6,
var = 0x4b,
nvars = 40862230
}
gcpro3 = {
next = 0x0,
var = 0x0,
nvars = 12
}
gcpro4 = {
next = 0x26f8216,
var = 0x16012e3993,
nvars = 12866354
}
---Type <return> to continue, or q <return> to quit---
display = 40495777
dpyinfo = 0x10a9940
parent = 12741074
kb = 0x1091c00
#24 0x00000000005ffa39 in Ffuncall (nargs=2, args=0x7fffffff8a60)
at eval.c:2974
fun = 9368773
original_fun = 13048258
funcar = 12741074
numargs = 1
lisp_numargs = 40840886
val = 40862230
backtrace = {
next = 0x7fffffff8ea0,
function = 0x7fffffff8a60,
args = 0x7fffffff8a68,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x7fffffff8a68
i = 13375296
#25 0x000000000064b475 in exec_byte_code (bytestr=9908065, vector=9908101,
maxdepth=16, args_template=12741074, nargs=0, args=0x0) at bytecode.c:785
---Type <return> to continue, or q <return> to quit---
count = 15
op = 1
vectorp = 0x972f90
stack = {
pc = 0xb6224c "\024Ύ\317\f!\210\320\f\b\"\210\321\f\322\"\210\323\f\b\"\210\n\204W",
byte_string = 9908065,
byte_string_start = 0xb62216 "\306\b!\020\307\b!\031\310\b\236\032\311\033ʉ\034\035\v\312\036\026\211\036\027\203\060",
constants = 9908101,
next = 0x7fffffff8fa0
}
top = 0x7fffffff8a60
result = 0
#26 0x00000000006004a4 in funcall_lambda (fun=9907997, nargs=1,
arg_vector=0x972f85) at eval.c:3205
val = 1
syms_left = 12741074
next = 13559378
lexenv = 12741074
count = 14
i = 1
optional = 1
---Type <return> to continue, or q <return> to quit---
rest = 0
#27 0x00000000005ffc4b in Ffuncall (nargs=2, args=0x7fffffff8f30)
at eval.c:3023
fun = 9907997
original_fun = 13375106
funcar = 19806420
numargs = 1
lisp_numargs = 12923922
val = 12741074
backtrace = {
next = 0x7fffffff9380,
function = 0x7fffffff8f30,
args = 0x7fffffff8f38,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x200
i = 18695024
#28 0x000000000064b475 in exec_byte_code (bytestr=10554729, vector=10554765,
maxdepth=20, args_template=12741074, nargs=0, args=0x0) at bytecode.c:785
count = 9
op = 1
vectorp = 0xa10d98
---Type <return> to continue, or q <return> to quit---
stack = {
pc = 0xb2cfcf "\026\027\320\016\027!\210\016\035\311\036\036\211\036\037\203", <incomplete sequence \354>,
byte_string = 10554729,
byte_string_start = 0xb2cf1f "\306\b\236\203,",
constants = 10554765,
next = 0x7fffffff9470
}
top = 0x7fffffff8f30
result = 29
#29 0x00000000006004a4 in funcall_lambda (fun=10554669, nargs=1,
arg_vector=0xa10d8d) at eval.c:3205
val = 10552905
syms_left = 12741074
next = 13559378
lexenv = 12741074
count = 8
i = 1
optional = 1
rest = 0
#30 0x00000000005ffc4b in Ffuncall (nargs=2, args=0x7fffffff9410)
at eval.c:3023
fun = 10554669
---Type <return> to continue, or q <return> to quit---
original_fun = 13811954
funcar = 140737488327680
numargs = 1
lisp_numargs = 6293965
val = 40862342
backtrace = {
next = 0x7fffffff9850,
function = 0x7fffffff9410,
args = 0x7fffffff9418,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x180
i = 12741074
#31 0x000000000064b475 in exec_byte_code (bytestr=10552641, vector=10552677,
maxdepth=16, args_template=12741074, nargs=0, args=0x0) at bytecode.c:785
count = 8
op = 1
vectorp = 0xa10570
stack = {
pc = 0xb2d227 "\207",
byte_string = 10552641,
byte_string_start = 0xb2d1cb "\306\307!\203\037",
---Type <return> to continue, or q <return> to quit---
constants = 10552677,
next = 0x7fffffff9990
}
top = 0x7fffffff9410
result = 40862598
#32 0x00000000006004a4 in funcall_lambda (fun=10552565, nargs=2,
arg_vector=0xa10565) at eval.c:3205
val = 40862598
syms_left = 12741074
next = 13559378
lexenv = 12741074
count = 6
i = 2
optional = 1
rest = 0
#33 0x00000000005ffc4b in Ffuncall (nargs=3, args=0x7fffffff9920)
at eval.c:3023
fun = 10552565
original_fun = 15996290
funcar = 0
numargs = 2
lisp_numargs = 0
val = 40862390
---Type <return> to continue, or q <return> to quit---
backtrace = {
next = 0x7fffffff9d70,
function = 0x7fffffff9920,
args = 0x7fffffff9928,
nargs = 2,
debug_on_exit = 0
}
internal_args = 0x7fffffff9e90
i = 12903362
#34 0x000000000064b475 in exec_byte_code (bytestr=30250433, vector=30253029,
maxdepth=52, args_template=5136, nargs=5, args=0x7fffffff9eb8)
at bytecode.c:785
count = 6
op = 2
vectorp = 0x1cd9ff0
stack = {
pc = 0x1c24d5a "\262\001\305\326\327\003\"\006\a\"\210\330\001!\210\331\006\006\332\003#\210\331\006\006\333\334\004!#\210\335\336\337!\340\"\210\207",
byte_string = 30250433,
byte_string_start = 0x1c24d08 "\300\301\302\"\210\303\304!\204\027",
constants = 30253029,
next = 0x7fffffff9f40
---Type <return> to continue, or q <return> to quit---
}
top = 0x7fffffff9920
result = 12741074
#35 0x0000000000600178 in funcall_lambda (fun=30253509, nargs=5,
arg_vector=0x7fffffff9e90) at eval.c:3139
val = 12741074
syms_left = 5136
next = 4294967296
lexenv = 2
count = 6
i = 140737488325488
optional = 0
rest = 4000
#36 0x00000000005ffc4b in Ffuncall (nargs=6, args=0x7fffffff9e88)
at eval.c:3023
fun = 30253509
original_fun = 30227618
funcar = 12741074
numargs = 5
lisp_numargs = 30261057
val = 12741074
backtrace = {
next = 0x7fffffffa320,
---Type <return> to continue, or q <return> to quit---
function = 0x7fffffff9e88,
args = 0x7fffffff9e90,
nargs = 5,
debug_on_exit = 0
}
internal_args = 0x7fffffffa3c8
i = 4
#37 0x000000000064b475 in exec_byte_code (bytestr=30257729, vector=31398373,
maxdepth=128, args_template=0, nargs=0, args=0x7fffffffa3c8)
at bytecode.c:785
count = 6
op = 5
vectorp = 0x1df19f0
stack = {
pc = 0x1c25512 "\202\024\003\005@\205\024\003\201O",
byte_string = 30257729,
byte_string_start = 0x1c25210 "\305\300!\210\306\300\307\310\311 !\312Q\"\210\313\312\301@\"\204&",
constants = 31398373,
next = 0x7fffffffa760
}
top = 0x7fffffff9e88
result = 12741074
---Type <return> to continue, or q <return> to quit---
#38 0x0000000000600178 in funcall_lambda (fun=41183989, nargs=0,
arg_vector=0x7fffffffa3c8) at eval.c:3139
val = 17179869184
syms_left = 0
next = 4294967295
lexenv = 48
count = 6
i = 14
optional = 0
rest = 0
#39 0x00000000005ffc4b in Ffuncall (nargs=1, args=0x7fffffffa3c0)
at eval.c:3023
fun = 41183989
original_fun = 41183989
funcar = 2
numargs = 0
lisp_numargs = 6136368
val = 140737488331728
backtrace = {
next = 0x7fffffffa490,
function = 0x7fffffffa3c0,
args = 0x7fffffffa3c8,
nargs = 0,
---Type <return> to continue, or q <return> to quit---
debug_on_exit = 0
}
internal_args = 0x7fffffffa3c0
i = 41091136
#40 0x00000000005fe29d in eval_sub (form=40798342) at eval.c:2294
vals = 0x7fffffffa3c0
argnum = 1
sa_count = 6
sa_must_free = 0
numargs = 4
args_left = 12741074
i = -23616
maxargs = 12741074
argvals = {4208, 17200861749, 140737488331824, 6144291, 0, 39369040,
140737261112960, 48}
fun = 12111453
val = 140737488332112
original_fun = 12865122
original_args = 40798358
funcar = 140737488332560
backtrace = {
next = 0x7fffffffab40,
function = 0x7fffffffa4c8,
---Type <return> to continue, or q <return> to quit---
args = 0x7fffffffa3c0,
nargs = 1,
debug_on_exit = 0
}
gcpro1 = {
next = 0x5,
var = 0x5da230,
nvars = 80
}
gcpro2 = {
next = 0x2730040,
var = 0x258b950,
nvars = 140737488331936
}
gcpro3 = {
next = 0x5,
var = 0x7fffffffa3c0,
nvars = 1
}
#41 0x00000000005fc55c in internal_lisp_condition_case (var=30257938,
bodyform=40798342, handlers=40798246) at eval.c:1453
val = 12741074
c = {
---Type <return> to continue, or q <return> to quit---
tag = 12741074,
val = 12741074,
next = 0x7fffffffad90,
gcpro = 0x0,
jmp = {{
__jmpbuf = {140737488333800, -1323075187161163761, 12741074,
30227042, 0, 0, -1323075187112929265, 1323074641310652431},
__mask_was_saved = 0,
__saved_mask = {
__val = {12741074, 140737488332480, 6289701, 140737488332080,
0, 140737488332528, 6, 140737488333632, 140737488332528,
140737488332536, 5, 0, 140737488332512, 40798310, 12865122,
12806098}
}
}},
backlist = 0x7fffffffab40,
handlerlist = 0x7fffffffb510,
lisp_eval_depth = 3,
pdlcount = 6,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x7fffffffa760
}
---Type <return> to continue, or q <return> to quit---
h = {
handler = 40798246,
var = 30257938,
chosen_clause = 140737488332240,
tag = 0x7fffffffa5a0,
next = 0x7fffffffb510
}
#42 0x000000000064c12e in exec_byte_code (bytestr=30256865, vector=20979829,
maxdepth=40, args_template=0, nargs=0, args=0x7fffffffabe8)
at bytecode.c:981
handlers = 40798246
body = 40798342
count = 6
op = 143
vectorp = 0x1402080
stack = {
pc = 0x1c25147 "\207",
byte_string = 30256865,
byte_string_start = 0x1c250b8 "\302\303\301@P\300\"\210\304\300\305\"\204V",
constants = 20979829,
next = 0x7fffffffaf50
}
---Type <return> to continue, or q <return> to quit---
top = 0x7fffffffa6d0
result = 0
#43 0x0000000000600178 in funcall_lambda (fun=23586533, nargs=0,
arg_vector=0x7fffffffabe8) at eval.c:3139
val = 12741074
syms_left = 0
next = 17179869184
lexenv = 48
count = 6
i = 140737261112960
optional = 0
rest = 20979824
#44 0x00000000005ffc4b in Ffuncall (nargs=1, args=0x7fffffffabe0)
at eval.c:3023
fun = 23586533
original_fun = 23586533
funcar = 40
numargs = 0
lisp_numargs = 30077512146
val = 2
backtrace = {
next = 0x7fffffffacb0,
function = 0x7fffffffabe0,
---Type <return> to continue, or q <return> to quit---
args = 0x7fffffffabe8,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x7fffffffabe0
i = 100000000
#45 0x00000000005fe29d in eval_sub (form=40798374) at eval.c:2294
vals = 0x7fffffffabe0
argnum = 1
sa_count = 6
sa_must_free = 0
numargs = 4
args_left = 12741074
i = -21536
maxargs = 12741074
argvals = {5, 0, 0, 140737257928336, 20979824, 23586528,
140737488333952, 12741074}
fun = 12111453
val = 4294946656
original_fun = 12865122
original_args = 40798390
funcar = 152
backtrace = {
---Type <return> to continue, or q <return> to quit---
next = 0x7fffffffb330,
function = 0x7ffffffface8,
args = 0x7fffffffabe0,
nargs = 1,
debug_on_exit = 0
}
gcpro1 = {
next = 0x5,
var = 0x700000000,
nvars = 23586584
}
gcpro2 = {
next = 0x27ef4a0,
var = 0x167e6e0,
nvars = 140737488334032
}
gcpro3 = {
next = 0x5,
var = 0x7fffffffabe0,
nvars = 1
}
#46 0x00000000005fc050 in internal_catch (tag=30227906,
func=0x5fdd25 <eval_sub>, arg=40798374) at eval.c:1256
---Type <return> to continue, or q <return> to quit---
c = {
tag = 30227906,
val = 12741074,
next = 0x7fffffffb540,
gcpro = 0x0,
jmp = {{
__jmpbuf = {140737488335816, -1323075187417016305, 12741074,
30227042, 0, 0, -1323075187377170417, 1323074641464530959},
__mask_was_saved = 0,
__saved_mask = {
__val = {6289701, 0, 0, 140737488334552, 6, 140737488335664,
140737488334552, 140737488334560, 5, 12741074, 12741074,
140737488334544, 6175427, 12806098, 0, 5}
}
}},
backlist = 0x7fffffffb330,
handlerlist = 0x7fffffffb510,
lisp_eval_depth = 1,
pdlcount = 6,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x7fffffffaf50
}
---Type <return> to continue, or q <return> to quit---
#47 0x000000000064c0be in exec_byte_code (bytestr=30255249, vector=30289701,
maxdepth=48, args_template=2056, nargs=2, args=0x7fffffffb3d8)
at bytecode.c:966
v1 = 40798374
count = 6
op = 141
vectorp = 0x1ce2f30
stack = {
pc = 0x1c2507d "\207",
byte_string = 30255249,
byte_string_start = 0x1c25068 "\211C\300\301\302\303\304\305\306\006\t\006\b\"\307\"\310\311%D\215\207",
constants = 30289701,
next = 0x0
}
top = 0x7fffffffaec8
result = 40777526
#48 0x0000000000600178 in funcall_lambda (fun=30290005, nargs=2,
arg_vector=0x7fffffffb3c8) at eval.c:3139
val = 1
syms_left = 2056
next = 6597069770240
lexenv = 1116504333322
---Type <return> to continue, or q <return> to quit---
count = 6
i = 268435456
optional = 0
rest = 12563984
#49 0x00000000005ffc4b in Ffuncall (nargs=3, args=0x7fffffffb3c0)
at eval.c:3023
fun = 30290005
original_fun = 30227042
funcar = 140737488335760
numargs = 2
lisp_numargs = 6173970
val = 140737488335808
backtrace = {
next = 0x0,
function = 0x7fffffffb3c0,
args = 0x7fffffffb3c8,
nargs = 2,
debug_on_exit = 0
}
internal_args = 0x7fffffffb3c0
i = 12906096
#50 0x00000000005febe6 in Fapply (nargs=2, args=0x7fffffffb480) at eval.c:2479
i = 3
---Type <return> to continue, or q <return> to quit---
numargs = 2
spread_arg = 12741074
funcall_args = 0x7fffffffb3c0
fun = 30290005
retval = 4973694
gcpro1 = {
next = 0x7fffffffb410,
var = 0x589c32,
nvars = 3
}
sa_count = 6
sa_must_free = 0
#51 0x00000000005ff133 in apply1 (fn=30227042, arg=40798438) at eval.c:2717
ret_ungc_val = 13414437
args = {30227042, 40798438}
gcpro1 = {
next = 0x4be3f9,
var = 0x7fffffffb480,
nvars = 2
}
#52 0x0000000000656f98 in read_process_output_call (fun_and_args=40798422)
at process.c:4967
No locals.
---Type <return> to continue, or q <return> to quit---
#53 0x00000000005fc83d in internal_condition_case_1 (
bfun=0x656f6a <read_process_output_call>, arg=40798422, handlers=12793266,
hfun=0x656f9a <read_process_output_error_handler>) at eval.c:1537
val = 12793266
c = {
tag = 12741074,
val = 12741074,
next = 0x7fffffffd590,
gcpro = 0x0,
jmp = {{
__jmpbuf = {12793266, -1323075186603321329, 67, 30227042, 0, 0,
-1323075186555086833, 1323074641215363087},
__mask_was_saved = 0,
__saved_mask = {
__val = {4300774963, 12741074, 12769125, 12552544, 12769120,
12741074, 43479120, 140737488336400, 12789760, 5807616,
13997941, 12741074, 67, 67, 25776097741, 12741122}
}
}},
backlist = 0x0,
handlerlist = 0x7fffffffd560,
lisp_eval_depth = 0,
pdlcount = 6,
---Type <return> to continue, or q <return> to quit---
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 12793266,
var = 12741074,
chosen_clause = 0,
tag = 0x7fffffffb540,
next = 0x7fffffffd560
}
#54 0x0000000000657632 in read_process_output (proc=43479125, channel=67)
at process.c:5167
text = 41193569
outer_running_asynch_code = 0
waiting = -1
nbytes = 67
chars = 0x7fffffffb680 ":0.0 -window-system -file /home/horn/Protokoll-Westerwaldbank.txt \nare/man:/usr/share/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.21.1/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/man:/etc"...
outstream = 30227042
p = 0xc335b2
opoint = 30227042
---Type <return> to continue, or q <return> to quit---
coding = 0x15a7400
carryover = 0
readmax = 4096
count = 3
odeactivate = 12741074
#55 0x00000000006568d6 in wait_reading_process_output (time_limit=30,
microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=12741074,
wait_proc=0x0, just_wait_proc=0) at process.c:4804
nread = 0
timeout_reduced_for_timers = 1
channel = 20
nfds = 1
Available = {
fds_bits = {1048576, 0 <repeats 15 times>}
}
Writeok = {
fds_bits = {0 <repeats 16 times>}
}
check_write = 1
check_delay = 1
no_avail = 0
xerrno = 11
proc = 43479125
---Type <return> to continue, or q <return> to quit---
timeout = {
tv_sec = 0,
tv_usec = 59875
}
end_time = {
tv_sec = 1318401682,
tv_usec = 489297
}
wait_channel = -1
got_some_input = 1
count = 2
#56 0x0000000000423225 in sit_for (timeout=120, reading=1, do_display=1)
at dispnew.c:5971
sec = 30
usec = 0
#57 0x0000000000565f2c in read_char (commandflag=1, nmaps=9,
maps=0x7fffffffcf40, prev_event=12741074, used_mouse_menu=0x7fffffffd164,
end_time=0x0) at keyboard.c:2687
tem0 = 0
timeout = 30
delay_level = 4
buffer_size = 1
c = 12741074
---Type <return> to continue, or q <return> to quit---
jmpcount = 2
local_getcjmp = {{
__jmpbuf = {9, -1323075188503341041, 4286720, 140737488346352, 0,
0, -1323075188387997681, 1323074723291076623},
__mask_was_saved = 0,
__saved_mask = {
__val = {780, 140737488342800, 6208925, 0, 0, 0, 0, 0, 12769120,
0, 12775154, 140737488342544, 6737913, 0, 5, 8589934627}
}
}}
save_jump = {{
__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>}
}
}}
key_already_recorded = 0
tem = 5754146
save = 140737488343400
previous_echo_area_message = 12741074
also_record = 12741074
reread = 0
---Type <return> to continue, or q <return> to quit---
gcpro1 = {
next = 0x7fffffffcc10,
var = 0x66cdb7,
nvars = 140737488342064
}
gcpro2 = {
next = 0xffffcbe0,
var = 0x7fffffffcc38,
nvars = 12741074
}
polling_stopped_here = 0
orig_kboard = 0x1091c00
#58 0x0000000000572e19 in read_key_sequence (keybuf=0x7fffffffd3d0,
bufsize=30, prompt=12741074, dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9282
interrupted_kboard = 0x1091c00
interrupted_frame = 0x1452e00
key = 12769125
used_mouse_menu = 0
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
local_first_binding = 0
---Type <return> to continue, or q <return> to quit---
from_string = 12741074
count = 2
t = 0
echo_start = 0
keys_start = 0
nmaps = 9
nmaps_allocated = 9
defs = 0x7fffffffcee0
submaps = 0x7fffffffcf40
orig_local_map = 15860886
orig_keymap = 12741074
localized_local_map = 0
first_binding = 0
first_unbound = 31
mock_input = 0
fkey = {
parent = 18142822,
map = 18142822,
start = 0,
end = 0
}
keytran = {
parent = 12720550,
---Type <return> to continue, or q <return> to quit---
map = 12720550,
start = 0,
end = 0
}
indec = {
parent = 18142806,
map = 18142806,
start = 0,
end = 0
}
shift_translated = 0
delayed_switch_frame = 12741074
original_uppercase = 196
original_uppercase_position = -1
dummyflag = 0
starting_buffer = 0xc2d760
fake_prefixed_keys = 12741074
outer_gcpro1 = {
next = 0x7fffffffd1a0,
var = 0x5e3512,
nvars = 21268741
}
#59 0x0000000000563692 in command_loop_1 () at keyboard.c:1447
---Type <return> to continue, or q <return> to quit---
cmd = 14035666
keybuf = {536871144, 212, 192, 6174127, 140737488344160, 12741074,
276967387, 1, 140737488344160, 6176458, 12741074, 12863618,
140737488344240, 6175427, 12578912, 8589923456, 0, 12863616,
140737488344320, 6294545, 12985638, 8589934593, 12863618, 12741074,
0, 0, 4286720, 140737488346352, 140737488344320, 6293965}
i = 1
prev_modiff = 15
prev_buffer = 0xc2d760
already_adjusted = 0
#60 0x00000000005fc6c4 in internal_condition_case (
bfun=0x5632a9 <command_loop_1>, handlers=12793266,
hfun=0x562b99 <cmd_error>) at eval.c:1499
val = 0
c = {
tag = 12741074,
val = 12741074,
next = 0x7fffffffd710,
gcpro = 0x0,
jmp = {{
__jmpbuf = {1, -1323075187687548913, 4286720, 140737488346352,
0, 0, -1323075187647703025, 1323074641263728655},
__mask_was_saved = 0,
---Type <return> to continue, or q <return> to quit---
__saved_mask = {
__val = {1323074641263728655, 0, 4294967295, 5696316, 1,
9343624, 0, 0, 0, 0, 140737351956354, 1, 0, 1,
140737257473672, 0}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 12793266,
var = 12741074,
chosen_clause = 12793266,
tag = 0x7fffffffd590,
next = 0x0
}
#61 0x0000000000562f99 in command_loop_2 (ignore=12741074) at keyboard.c:1158
val = 1
---Type <return> to continue, or q <return> to quit---
#62 0x00000000005fc050 in internal_catch (tag=12789058,
func=0x562f73 <command_loop_2>, arg=12741074) at eval.c:1256
c = {
tag = 12789058,
val = 12741074,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {1, -1323075187735783409, 4286720, 140737488346352,
0, 0, -1323075187695937521, 1323074641464530959},
__mask_was_saved = 0,
__saved_mask = {
__val = {6175427, 112, 4301654456, 140737261113048, 12741074,
12134176, 12769120, 14, 1, 140737488345072, 12968192,
140737488345136, 12741074, 4286720, 140737488346352,
140737488345152}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
---Type <return> to continue, or q <return> to quit---
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#63 0x0000000000562f4c in command_loop () at keyboard.c:1137
No locals.
#64 0x00000000005626df in recursive_edit_1 () at keyboard.c:757
count = 1
val = 12741074
#65 0x0000000000562881 in Frecursive_edit () at keyboard.c:821
count = 0
buffer = 12741074
#66 0x00000000005609f5 in main (argc=1, argv=0x7fffffffdcf8) at emacs.c:1706
dummy = 140737353901264
stack_bottom_variable = 0 '\000'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
---Type <return> to continue, or q <return> to quit---
ch_to_dir = 0x7ffff7fbfea0 "@\344\377\367\377\177"
Lisp Backtrace:
"x-create-frame" (0xffff8a68)
"x-create-frame-with-faces" (0xffff8f38)
"make-frame" (0xffff9418)
"make-frame-on-display" (0xffff9928)
"server-create-window-system-frame" (0xffff9e90)
0x2746af0 PVEC_COMPILED
"funcall" (0xffffa3c0)
0x167e6e0 PVEC_COMPILED
"funcall" (0xffffabe0)
"server-process-filter" (0xffffb3c8)
(gdb)
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-12 6:49 ` Tassilo Horn
@ 2011-10-12 12:57 ` Stefan Monnier
2011-11-17 10:10 ` Tassilo Horn
0 siblings, 1 reply; 39+ messages in thread
From: Stefan Monnier @ 2011-10-12 12:57 UTC (permalink / raw)
To: Tassilo Horn
Cc: Chong Yidong, emacs-devel, schwab, James Cloos, Eli Zaretskii,
Jan D., Ulrich Mueller
> I commente 3 lines as indicated below:
> --8<---------------cut here---------------start------------->8---
> /* If needed, delete the terminal that this frame was on.
> (This must be done after the frame is killed.) */
> terminal->reference_count--;
> if (terminal->reference_count == 0)
> {
> // Lisp_Object tmp;
> // XSETTERMINAL (tmp, terminal);
> kb = NULL;
> // Fdelete_terminal (tmp, NILP (force) ? Qt : force);
> }
> else
> kb = terminal->kboard;
> --8<---------------cut here---------------end--------------->8---
> I'm not sure if keeping the "kb = NULL;" was correct, though. If you
> want, I can try again with the complete then block commented.
I'd suggest to only comment out the "terminal->reference_count--;".
Stefan
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-10-12 12:57 ` Stefan Monnier
@ 2011-11-17 10:10 ` Tassilo Horn
2011-11-17 11:18 ` Chong Yidong
2011-11-18 2:05 ` Stefan Monnier
0 siblings, 2 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-11-17 10:10 UTC (permalink / raw)
To: Stefan Monnier
Cc: Chong Yidong, emacs-devel, schwab, James Cloos, Eli Zaretskii,
Jan D., Ulrich Mueller
Stefan Monnier <monnier@iro.umontreal.ca> writes:
Hi Stefan,
>> I commente 3 lines as indicated below:
>
>> --8<---------------cut here---------------start------------->8---
>> /* If needed, delete the terminal that this frame was on.
>> (This must be done after the frame is killed.) */
>> terminal->reference_count--;
>> if (terminal->reference_count == 0)
>> {
>> // Lisp_Object tmp;
>> // XSETTERMINAL (tmp, terminal);
>
>> kb = NULL;
>> // Fdelete_terminal (tmp, NILP (force) ? Qt : force);
>> }
>> else
>> kb = terminal->kboard;
>> --8<---------------cut here---------------end--------------->8---
>
>> I'm not sure if keeping the "kb = NULL;" was correct, though. If you
>> want, I can try again with the complete then block commented.
>
> I'd suggest to only comment out the "terminal->reference_count--;".
I did that by using the patch below for about one month. Since then,
the crashes I had are gone, and working with multiple emacs X frames is
fun again. Should I go ahead and commit?
--8<---------------cut here---------------start------------->8---
=== modified file 'src/frame.c'
--- src/frame.c 2011-11-17 09:09:20 +0000
+++ src/frame.c 2011-11-17 10:05:11 +0000
@@ -1358,7 +1358,11 @@
/* If needed, delete the terminal that this frame was on.
(This must be done after the frame is killed.) */
- terminal->reference_count--;
+
+ // FIXME: Deleting the terminal crashes emacs because of a GTK
+ // bug. See the thread starting with <87d3flnxoo.fsf@thinkpad.tsdh.de>
+ // on emacs-devel.
+ // terminal->reference_count--;
if (terminal->reference_count == 0)
{
Lisp_Object tmp;
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
--
(What the world needs (I think) is not
(a Lisp (with fewer parentheses))
but (an English (with more.)))
Brian Hayes, http://tinyurl.com/3y9l2kf
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-11-17 10:10 ` Tassilo Horn
@ 2011-11-17 11:18 ` Chong Yidong
2011-11-17 13:45 ` Tassilo Horn
2011-11-18 2:05 ` Stefan Monnier
1 sibling, 1 reply; 39+ messages in thread
From: Chong Yidong @ 2011-11-17 11:18 UTC (permalink / raw)
To: Tassilo Horn
Cc: Ulrich Mueller, emacs-devel, schwab, Stefan Monnier, James Cloos,
Eli Zaretskii, Jan D.
Tassilo Horn <tassilo@member.fsf.org> writes:
> I did that by using the patch below for about one month. Since then,
> the crashes I had are gone, and working with multiple emacs X frames is
> fun again. Should I go ahead and commit?
Fine by me, but the code should probably be something like
#ifdef USE_GTK
/* ... (Use C-style not C++ style comments) ... */
if (terminal->type != output_x_window)
#endif
terminal->reference_count--;
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-11-17 11:18 ` Chong Yidong
@ 2011-11-17 13:45 ` Tassilo Horn
2011-11-17 16:34 ` Paul Eggert
0 siblings, 1 reply; 39+ messages in thread
From: Tassilo Horn @ 2011-11-17 13:45 UTC (permalink / raw)
To: Chong Yidong
Cc: Ulrich Mueller, emacs-devel, schwab, Stefan Monnier, James Cloos,
Eli Zaretskii, Jan D.
Chong Yidong <cyd@gnu.org> writes:
>> I did that by using the patch below for about one month. Since then,
>> the crashes I had are gone, and working with multiple emacs X frames
>> is fun again. Should I go ahead and commit?
>
> Fine by me, but the code should probably be something like
>
> #ifdef USE_GTK
> /* ... (Use C-style not C++ style comments) ... */
> if (terminal->type != output_x_window)
> #endif
> terminal->reference_count--;
So the one below is fine, right? What about the indentation of the line
after the #endif? Emacs' <tab> wants it to be correct in the USE_GTK
case, while you have it correct in the other case.
--8<---------------cut here---------------start------------->8---
=== modified file 'src/frame.c'
--- src/frame.c 2011-11-17 09:09:20 +0000
+++ src/frame.c 2011-11-17 13:40:27 +0000
@@ -1358,7 +1358,14 @@
/* If needed, delete the terminal that this frame was on.
(This must be done after the frame is killed.) */
- terminal->reference_count--;
+
+#ifdef USE_GTK
+ /* FIXME: Deleting the terminal crashes emacs because of a GTK
+ bug. See the thread starting with
+ <87d3flnxoo.fsf@thinkpad.tsdh.de> on emacs-devel. */
+ if (terminal->type != output_x_window)
+#endif /* USE_GTK */
+ terminal->reference_count--;
if (terminal->reference_count == 0)
{
Lisp_Object tmp;
--8<---------------cut here---------------end--------------->8---
Bye,
Tassilo
--
(What the world needs (I think) is not
(a Lisp (with fewer parentheses))
but (an English (with more.)))
Brian Hayes, http://tinyurl.com/3y9l2kf
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-11-17 13:45 ` Tassilo Horn
@ 2011-11-17 16:34 ` Paul Eggert
2011-11-17 16:58 ` Tassilo Horn
2011-11-18 2:41 ` Chong Yidong
0 siblings, 2 replies; 39+ messages in thread
From: Paul Eggert @ 2011-11-17 16:34 UTC (permalink / raw)
To: Tassilo Horn; +Cc: emacs-devel
On 11/17/11 05:45, Tassilo Horn wrote:
> +#ifdef USE_GTK
> + /* FIXME: Deleting the terminal crashes emacs because of a GTK
> + bug. See the thread starting with
> + <87d3flnxoo.fsf@thinkpad.tsdh.de> on emacs-devel. */
> + if (terminal->type != output_x_window)
> +#endif /* USE_GTK */
> + terminal->reference_count--;
Could you please use a URL rather than a Message-ID? The latter
is hard for a random reader to follow. Perhaps the URL
<http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00363.html>
is what is meant? (Sorry, I can't easily tell.)
Also, this code would be easier to read:
if (! (use_gtk && terminal->type == output_x_window))
terminal->reference_count--;
with something like this near the start of the file:
#ifdef USE_GTK
enum { use_gtk = 1 };
#else
enum { use_gtk = 0 };
#endif
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-11-17 16:34 ` Paul Eggert
@ 2011-11-17 16:58 ` Tassilo Horn
2011-11-18 2:41 ` Chong Yidong
1 sibling, 0 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-11-17 16:58 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
Paul Eggert <eggert@cs.ucla.edu> writes:
Hi Paul,
> On 11/17/11 05:45, Tassilo Horn wrote:
>> +#ifdef USE_GTK
>> + /* FIXME: Deleting the terminal crashes emacs because of a GTK
>> + bug. See the thread starting with
>> + <87d3flnxoo.fsf@thinkpad.tsdh.de> on emacs-devel. */
>> + if (terminal->type != output_x_window)
>> +#endif /* USE_GTK */
>> + terminal->reference_count--;
>
> Could you please use a URL rather than a Message-ID? The latter is
> hard for a random reader to follow. Perhaps the URL
> <http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00363.html>
> is what is meant? (Sorry, I can't easily tell.)
Yes, the Message-ID was the top-level message of that thread, but the
link you cite is actually where the important information drops in.
> Also, this code would be easier to read:
>
> if (! (use_gtk && terminal->type == output_x_window))
> terminal->reference_count--;
>
> with something like this near the start of the file:
>
> #ifdef USE_GTK
> enum { use_gtk = 1 };
> #else
> enum { use_gtk = 0 };
> #endif
In my opinion, it's better to keep temporary workarounds for buggy
external libs as local as possible. But I don't really care, as long as
it fixes the crashes.
Bye,
Tassilo
--
(What the world needs (I think) is not
(a Lisp (with fewer parentheses))
but (an English (with more.)))
Brian Hayes, http://tinyurl.com/3y9l2kf
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-11-17 10:10 ` Tassilo Horn
2011-11-17 11:18 ` Chong Yidong
@ 2011-11-18 2:05 ` Stefan Monnier
2011-11-18 9:38 ` Tassilo Horn
1 sibling, 1 reply; 39+ messages in thread
From: Stefan Monnier @ 2011-11-18 2:05 UTC (permalink / raw)
To: Tassilo Horn
Cc: Chong Yidong, emacs-devel, schwab, James Cloos, Eli Zaretskii,
Jan D., Ulrich Mueller
> I did that by using the patch below for about one month. Since then,
> the crashes I had are gone, and working with multiple emacs X frames is
> fun again. Should I go ahead and commit?
Good news, thanks.
> --8<---------------cut here---------------start------------->8---
> === modified file 'src/frame.c'
> --- src/frame.c 2011-11-17 09:09:20 +0000
> +++ src/frame.c 2011-11-17 10:05:11 +0000
> @@ -1358,7 +1358,11 @@
> /* If needed, delete the terminal that this frame was on.
> (This must be done after the frame is killed.) */
> - terminal->reference_count--;
> +
> + // FIXME: Deleting the terminal crashes emacs because of a GTK
> + // bug. See the thread starting with <87d3flnxoo.fsf@thinkpad.tsdh.de>
> + // on emacs-devel.
> + // terminal->reference_count--;
> if (terminal->reference_count == 0)
> {
> Lisp_Object tmp;
> --8<---------------cut here---------------end--------------->8---
To avoid the risk of reaching 0 via wrap-around (yes, I know that
creating a billion frames in the life of a single session is unlikely,
but still), you could do:
/* If needed, delete the terminal that this frame was on.
(This must be done after the frame is killed.) */
terminal->reference_count--;
#ifdef USE_GTK
/* ... (Use C-style not C++ style comments) ... */
if (terminal->reference_count == 0 && terminal->type == output_x_window)
terminal->reference_count = 1;
#endif
if (terminal->reference_count == 0)
{
Lisp_Object tmp;
Alternatively you could get the same result by changing the code that
initializes terminal->reference_count so that it starts at 1 rather than
at 0.
Stefan
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-11-17 16:34 ` Paul Eggert
2011-11-17 16:58 ` Tassilo Horn
@ 2011-11-18 2:41 ` Chong Yidong
1 sibling, 0 replies; 39+ messages in thread
From: Chong Yidong @ 2011-11-18 2:41 UTC (permalink / raw)
To: Paul Eggert; +Cc: Tassilo Horn, emacs-devel
Paul Eggert <eggert@cs.ucla.edu> writes:
> Also, this code would be easier to read:
>
> if (! (use_gtk && terminal->type == output_x_window))
> terminal->reference_count--;
>
> with something like this near the start of the file:
>
> #ifdef USE_GTK
> enum { use_gtk = 1 };
> #else
> enum { use_gtk = 0 };
> #endif
We don't follow this practice elsewhere in Emacs; let's not start now.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-11-18 2:05 ` Stefan Monnier
@ 2011-11-18 9:38 ` Tassilo Horn
2012-01-20 23:29 ` andres.ramirez
2012-01-20 23:29 ` andres.ramirez
0 siblings, 2 replies; 39+ messages in thread
From: Tassilo Horn @ 2011-11-18 9:38 UTC (permalink / raw)
To: Stefan Monnier
Cc: Chong Yidong, emacs-devel, schwab, James Cloos, Eli Zaretskii,
Jan D., Ulrich Mueller
Stefan Monnier <monnier@iro.umontreal.ca> writes:
Hi Stefan,
> To avoid the risk of reaching 0 via wrap-around (yes, I know that
> creating a billion frames in the life of a single session is unlikely,
> but still), you could do:
>
> /* If needed, delete the terminal that this frame was on.
> (This must be done after the frame is killed.) */
> terminal->reference_count--;
> #ifdef USE_GTK
> /* ... (Use C-style not C++ style comments) ... */
> if (terminal->reference_count == 0 && terminal->type == output_x_window)
> terminal->reference_count = 1;
> #endif
> if (terminal->reference_count == 0)
> {
> Lisp_Object tmp;
I liked this version best and it's committed now.
Bye,
Tassilo
--
(What the world needs (I think) is not
(a Lisp (with fewer parentheses))
but (an English (with more.)))
Brian Hayes, http://tinyurl.com/3y9l2kf
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-11-18 9:38 ` Tassilo Horn
@ 2012-01-20 23:29 ` andres.ramirez
2012-01-21 0:34 ` Glenn Morris
2012-01-20 23:29 ` andres.ramirez
1 sibling, 1 reply; 39+ messages in thread
From: andres.ramirez @ 2012-01-20 23:29 UTC (permalink / raw)
To: Tassilo Horn
Cc: Chong Yidong, emacs-devel, schwab, Stefan Monnier, James Cloos,
Eli Zaretskii, Jan D., Ulrich Mueller
Hi.
I have revno 106895. And this problem still persist.
emacs is configured as follows:
In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
of 2012-01-20 on wari
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
configured using `configure '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib' '--mandir=/usr/share/man/emacs-24' '--without-sound' '--program-suffix=-emacs-24' '--infodir=/usr/share/info/emacs-24' '--with-x-toolkit=gtk3' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu''
Regards
At Fri, 18 Nov 2011 10:38:39 +0100,
Tassilo Horn wrote:
>
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> Hi Stefan,
>
> > To avoid the risk of reaching 0 via wrap-around (yes, I know that
> > creating a billion frames in the life of a single session is unlikely,
> > but still), you could do:
> >
> > /* If needed, delete the terminal that this frame was on.
> > (This must be done after the frame is killed.) */
> > terminal->reference_count--;
> > #ifdef USE_GTK
> > /* ... (Use C-style not C++ style comments) ... */
> > if (terminal->reference_count == 0 && terminal->type == output_x_window)
> > terminal->reference_count = 1;
> > #endif
> > if (terminal->reference_count == 0)
> > {
> > Lisp_Object tmp;
>
> I liked this version best and it's committed now.
>
> Bye,
> Tassilo
> --
> (What the world needs (I think) is not
> (a Lisp (with fewer parentheses))
> but (an English (with more.)))
> Brian Hayes, http://tinyurl.com/3y9l2kf
>
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2011-11-18 9:38 ` Tassilo Horn
2012-01-20 23:29 ` andres.ramirez
@ 2012-01-20 23:29 ` andres.ramirez
1 sibling, 0 replies; 39+ messages in thread
From: andres.ramirez @ 2012-01-20 23:29 UTC (permalink / raw)
To: Tassilo Horn
Cc: Chong Yidong, emacs-devel, schwab, Stefan Monnier, James Cloos,
Eli Zaretskii, Jan D., Ulrich Mueller
Hi.
I have revno 106895. And this problem still persist.
emacs is configured as follows:
In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
of 2012-01-20 on wari
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
configured using `configure '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib' '--mandir=/usr/share/man/emacs-24' '--without-sound' '--program-suffix=-emacs-24' '--infodir=/usr/share/info/emacs-24' '--with-x-toolkit=gtk3' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu''
Regards
At Fri, 18 Nov 2011 10:38:39 +0100,
Tassilo Horn wrote:
>
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> Hi Stefan,
>
> > To avoid the risk of reaching 0 via wrap-around (yes, I know that
> > creating a billion frames in the life of a single session is unlikely,
> > but still), you could do:
> >
> > /* If needed, delete the terminal that this frame was on.
> > (This must be done after the frame is killed.) */
> > terminal->reference_count--;
> > #ifdef USE_GTK
> > /* ... (Use C-style not C++ style comments) ... */
> > if (terminal->reference_count == 0 && terminal->type == output_x_window)
> > terminal->reference_count = 1;
> > #endif
> > if (terminal->reference_count == 0)
> > {
> > Lisp_Object tmp;
>
> I liked this version best and it's committed now.
>
> Bye,
> Tassilo
> --
> (What the world needs (I think) is not
> (a Lisp (with fewer parentheses))
> but (an English (with more.)))
> Brian Hayes, http://tinyurl.com/3y9l2kf
>
>
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2012-01-20 23:29 ` andres.ramirez
@ 2012-01-21 0:34 ` Glenn Morris
2012-01-21 8:02 ` andres.ramirez
0 siblings, 1 reply; 39+ messages in thread
From: Glenn Morris @ 2012-01-21 0:34 UTC (permalink / raw)
To: andres.ramirez; +Cc: emacs-devel
andres.ramirez wrote:
> I have revno 106895. And this problem still persist.
>
> emacs is configured as follows:
> In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
> of 2012-01-20 on wari
If you have that revision, why is your version number not 24.0.92?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Killing a frame sometimes kills emacs
2012-01-21 0:34 ` Glenn Morris
@ 2012-01-21 8:02 ` andres.ramirez
0 siblings, 0 replies; 39+ messages in thread
From: andres.ramirez @ 2012-01-21 8:02 UTC (permalink / raw)
To: Glenn Morris; +Cc: andres.ramirez, emacs-devel
Hi Glenn.
the problem was my emacs-build directory, after removing it I got
In GNU Emacs 24.0.92.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
of 2012-01-20 on wari
Windowing system distributor `The X.Org Foundation', version
11.0.11103000
configured using `configure '--prefix=/usr' '--sysconfdir=/etc'
'--localstatedir=/var' '--libexecdir=/usr/lib'
'--mandir=/usr/share/man/emacs-24' '--without-sound'
'--program-suffix=-emacs-24' '--infodir=/usr/share/info/emacs-24'
'--with-x-toolkit=gtk3' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe
-fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2'
'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu''
And also the problem is GONE, sorry for bothering
Regards
At Fri, 20 Jan 2012 19:34:02 -0500,
Glenn Morris wrote:
>
> andres.ramirez wrote:
>
> > I have revno 106895. And this problem still persist.
> >
> > emacs is configured as follows:
> > In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
> > of 2012-01-20 on wari
>
> If you have that revision, why is your version number not 24.0.92?
>
>
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2012-01-21 8:02 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-31 20:16 Killing a frame sometimes kills emacs Tassilo Horn
2011-08-31 20:51 ` joakim
2011-08-31 23:06 ` chad
2011-09-01 2:53 ` Eli Zaretskii
2011-09-01 7:04 ` Tassilo Horn
2011-09-01 10:09 ` Tassilo Horn
2011-09-01 10:27 ` Eli Zaretskii
2011-09-01 10:42 ` Tassilo Horn
2011-09-01 10:56 ` Eli Zaretskii
2011-09-01 11:09 ` Tassilo Horn
2011-09-01 10:33 ` Andreas Schwab
2011-09-01 10:45 ` Tassilo Horn
2011-09-01 12:47 ` Jan D.
2011-09-01 13:05 ` Tassilo Horn
2011-09-01 15:29 ` Eli Zaretskii
2011-09-01 19:30 ` Ken Raeburn
2011-09-02 15:02 ` Andreas Schwab
2011-10-11 6:46 ` Tassilo Horn
2011-10-11 12:53 ` Stefan Monnier
2011-10-11 14:53 ` Tassilo Horn
2011-10-11 17:38 ` James Cloos
2011-10-11 19:17 ` Tassilo Horn
2011-10-11 19:49 ` Tassilo Horn
2011-10-12 2:04 ` Chong Yidong
2011-10-12 6:49 ` Tassilo Horn
2011-10-12 12:57 ` Stefan Monnier
2011-11-17 10:10 ` Tassilo Horn
2011-11-17 11:18 ` Chong Yidong
2011-11-17 13:45 ` Tassilo Horn
2011-11-17 16:34 ` Paul Eggert
2011-11-17 16:58 ` Tassilo Horn
2011-11-18 2:41 ` Chong Yidong
2011-11-18 2:05 ` Stefan Monnier
2011-11-18 9:38 ` Tassilo Horn
2012-01-20 23:29 ` andres.ramirez
2012-01-21 0:34 ` Glenn Morris
2012-01-21 8:02 ` andres.ramirez
2012-01-20 23:29 ` andres.ramirez
2011-10-11 17:56 ` Jan Djärv
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).