From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Ken Brown <kbrown@cornell.edu>, emacs-devel@gnu.org
Subject: Re: 64-bit emacs crashes a lot
Date: Fri, 16 Aug 2013 12:51:57 -0400 [thread overview]
Message-ID: <520E58AD.6050905@cs.utoronto.ca> (raw)
In-Reply-To: <83eh9tmyg7.fsf@gnu.org>
On 16/08/2013 11:45 AM, Eli Zaretskii wrote:
>> Date: Fri, 16 Aug 2013 10:20:00 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: Ryan Johnson <ryan.johnson@cs.utoronto.ca>, emacs-devel@gnu.org
>>
>> FWIW, I just tried this on the trunk, both with and without
>> optimization. The bug is still there in the optimized build
> Can you post a full backtrace from the crashed session?
I finally intercepted a SIGSEGV in gdb, from a debug-mode emacs. It's
pretty hard to repro (100-200 M-x compile cycles), so be patient...
Here's the stack trace (based on the emacs-24.3-4 source package on the
cygwin64 setup).
As usual, we've dereferenced a NULL pointer just after verifying that it
was not NULL. This is becoming a repeating theme; are there any
asynchronous actors in emacs that might invoke GC or otherwise frob
pointers?
Initial analysis follows:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1280.0xfc4]
> previous_interval (interval=0x6002181e0) at intervals.c:758
> 758 while (! NULL_RIGHT_CHILD (i))
> (gdb) p i
> $1 = (INTERVAL) 0x0
> (gdb) p interval
> $2 = (INTERVAL) 0x6002181e0
> (gdb) p *interval
> $3 = {total_length = 355, position = 99, left = 0x600218090, right =
> 0x0, up = {interval = 0x600070425, obj = 25770263589}, up_obj = 1,
> gcmarkbit = 0, write_protect = 0, visible = 0, front_sticky = 0,
> rear_sticky = 0, plist = 4307415122}
> (gdb) p interval->left->right
> $5 = (struct interval *) 0x600218138
> (gdb) p interval->left->right->right
> $6 = (struct interval *) 0x600218170
> (gdb) p interval->left->right->right->right
> $7 = (struct interval *) 0x6002181a8
> (gdb) p interval->left->right->right->right->right
> $8 = (struct interval *) 0x0
The relevant disassembly is:
> (gdb) disas previous_interval,+60
> 0x00000001006c1546 <previous_interval+0>: push %rbp
> 0x00000001006c1547 <previous_interval+1>: push %rbx
> 0x00000001006c1548 <previous_interval+2>: sub $0x28,%rsp
> 0x00000001006c154c <previous_interval+6>: lea 0x80(%rsp),%rbp
> 0x00000001006c1554 <previous_interval+14>: mov %rcx,%rax
> 0x00000001006c1557 <previous_interval+17>: test %rax,%rax
> 0x00000001006c155a <previous_interval+20>: jne 0x1006c1566
> <previous_interval+32>
%rax is the variable "interval", and if non-zero we jump to +32
> 0x00000001006c155c <previous_interval+22>: mov $0x0,%eax
> 0x00000001006c1561 <previous_interval+27>: jmpq 0x1006c1757
> <previous_interval+529>
> 0x00000001006c1566 <previous_interval+32>: mov 0x10(%rax),%rdx
> 0x00000001006c156a <previous_interval+36>: test %rdx,%rdx
> 0x00000001006c156d <previous_interval+39>: je 0x1006c15ea
> <previous_interval+164>
%rdx is interval->left, and if non-zero we fall through to +41
> 0x00000001006c156f <previous_interval+41>: mov 0x10(%rax),%rbx
> 0x00000001006c1573 <previous_interval+45>: jmp 0x1006c1579
> <previous_interval+51>
copy interval->left into %rbx as initial value of "i" and jump into loop
at +51
> 0x00000001006c1575 <previous_interval+47>: mov 0x18(%rbx),%rbx
loop body: set i = i->right
> => 0x00000001006c1579 <previous_interval+51>: mov 0x18(%rbx),%rdx
> 0x00000001006c157d <previous_interval+55>: test %rdx,%rdx
> 0x00000001006c1580 <previous_interval+58>: jne 0x1006c1575
> <previous_interval+47>
Loop test: if i->right != 0, execute the loop body, which loads i' =
i->right and then tests i'->right (i->right->right). Clobbers %rdx.
Overall the code seems fine. As usual, we loaded a non-NULL value into a
register (now clobbered, unfortunately) from a memory location that was
then zeroed out before the compiler could reload it into a second register.
The full backtrace is below, and I've got the session frozen in gdb. Let
me know if you want me to dig into anything else.
Ryan
(gdb) bt
#0 previous_interval (interval=0x6002181e0) at intervals.c:758
#1 0x00000001006c5301 in set_point_both (charpos=99, bytepos=99) at
intervals.c:1917
#2 0x00000001006c4a0e in set_point (charpos=99) at intervals.c:1820
#3 0x000000010060d567 in Fgoto_char (position=396) at editfns.c:242
#4 0x000000010069f74d in exec_byte_code (bytestr=4303941777,
vector=4303941957, maxdepth=24, args_template=4307415122, nargs=0,
args=0x0) at bytecode.c:1480
#5 0x0000000100629880 in funcall_lambda (fun=4303941725, nargs=3,
arg_vector=0x227718) at eval.c:3010
#6 0x0000000100628b49 in Ffuncall (nargs=4, args=0x227710) at eval.c:2827
#7 0x0000000100627464 in funcall_nil (nargs=4, args=0x227710) at
eval.c:2324
#8 0x00000001006279bf in run_hook_with_args (nargs=4, args=0x227710,
funcall=0x100627444 <funcall_nil>) at eval.c:2509
#9 0x0000000100627506 in Frun_hook_with_args (nargs=4, args=0x227710)
at eval.c:2370
#10 0x000000010062833d in Ffuncall (nargs=5, args=0x227708) at eval.c:2759
#11 0x000000010069ccce in exec_byte_code (bytestr=4303972225,
vector=4303972469, maxdepth=24, args_template=4307415122, nargs=0,
args=0x0) at bytecode.c:900
#12 0x0000000100629880 in funcall_lambda (fun=4303972157, nargs=3,
arg_vector=0x227d58) at eval.c:3010
#13 0x0000000100628b49 in Ffuncall (nargs=4, args=0x227d50) at eval.c:2827
#14 0x0000000100627464 in funcall_nil (nargs=4, args=0x227d50) at
eval.c:2324
#15 0x00000001006279bf in run_hook_with_args (nargs=4, args=0x227d50,
funcall=0x100627444 <funcall_nil>) at eval.c:2509
#16 0x0000000100627506 in Frun_hook_with_args (nargs=4, args=0x227d50)
at eval.c:2370
#17 0x0000000100599cd0 in signal_after_change (charpos=99, lendel=0,
lenins=257) at insdel.c:2058
#18 0x0000000100594fa9 in insert_from_string (string=25771578241, pos=0,
pos_byte=0, length=257, length_byte=257, inherit=false) at insdel.c:873
#19 0x0000000100613151 in general_insert_function
(insert_func=0x1005944ec <insert>, insert_from_string_func=0x100594ec8
<insert_from_string>, inherit=false, nargs=1, args=0x227ef8) at
editfns.c:2258
#20 0x00000001006131da in Finsert (nargs=1, args=0x227ef8) at editfns.c:2299
#21 0x000000010069f7a3 in exec_byte_code (bytestr=25772122625,
vector=4313861789, maxdepth=28, args_template=4307415122, nargs=0,
args=0x0) at bytecode.c:1486
#22 0x0000000100629880 in funcall_lambda (fun=4313861965, nargs=2,
arg_vector=0x228428) at eval.c:3010
#23 0x0000000100628b49 in Ffuncall (nargs=3, args=0x228420) at eval.c:2827
#24 0x0000000100627415 in Fapply (nargs=2, args=0x2284f0) at eval.c:2312
#25 0x0000000100627ae3 in apply1 (fn=25772023938, arg=4318413830) at
eval.c:2546
#26 0x00000001006af86e in read_process_output_call
(fun_and_args=4318413846) at process.c:5022
#27 0x0000000100623506 in internal_condition_case_1 (bfun=0x1006af7d7
<read_process_output_call>, arg=4318413846, handlers=4307507906,
hfun=0x1006af874 <read_process_output_error_handler>) at eval.c:1327
#28 0x00000001006b00bd in read_process_output (proc=4316041005,
channel=257) at process.c:5221
#29 0x00000001006aedb5 in wait_reading_process_output (time_limit=28,
nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=4307415122,
wait_proc=0x0, just_wait_proc=0) at process.c:4852
#30 0x0000000100412d28 in sit_for (timeout=112, reading=true,
display_option=1) at dispnew.c:5978
#31 0x0000000100542d2d in read_char (commandflag=1, nmaps=2,
maps=0x229f90, prev_event=4307415122, used_mouse_menu=0x22a157,
end_time=0x0) at keyboard.c:2669
#32 0x00000001005587ba in read_key_sequence (keybuf=0x22a400,
bufsize=30, prompt=4307415122, dont_downcase_last=false,
can_return_switch_frame=true, fix_current_buffer=true) at keyboard.c:9231
#33 0x000000010053e9c9 in command_loop_1 () at keyboard.c:1459
#34 0x0000000100623376 in internal_condition_case (bfun=0x10053e29a
<command_loop_1>, handlers=4307507906, hfun=0x10053d7bb <cmd_error>) at
eval.c:1289
#35 0x000000010053de20 in command_loop_2 (ignore=4307415122) at
keyboard.c:1168
#36 0x0000000100622bc2 in internal_catch (tag=4307491714,
func=0x10053ddee <command_loop_2>, arg=4307415122) at eval.c:1060
#37 0x000000010053ddaf in command_loop () at keyboard.c:1147
#38 0x000000010053ceea in recursive_edit_1 () at keyboard.c:779
#39 0x000000010053d371 in Frecursive_edit () at keyboard.c:843
#40 0x000000010053a687 in main (argc=2, argv=0x22ab20) at emacs.c:1532
next prev parent reply other threads:[~2013-08-16 16:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51F3151D.7040000@cs.utoronto.ca>
[not found] ` <51F33565.1090406@cornell.edu>
[not found] ` <51F33F52.4060405@cs.utoronto.ca>
[not found] ` <51FB1D9E.5090102@cs.utoronto.ca>
[not found] ` <20130802080211.GA18054@calimero.vinschen.de>
[not found] ` <51FB9228.2020309@cornell.edu>
[not found] ` <51FBA100.90005@cs.utoronto.ca>
[not found] ` <51FD5462.5020400@cs.utoronto.ca>
[not found] ` <51FFBDFF.7040501@cornell.edu>
[not found] ` <51FFC4F2.8080909@cs.utoronto.ca>
[not found] ` <5203D89E.6030801@cornell.edu>
[not found] ` <5203DCCA.1010105@cs.utoronto.ca>
[not found] ` <5205B364.8090007@cs.utoronto.ca>
[not found] ` <52064730.50404@cornell.edu>
[not found] ` <"52065B3C.6060104@cs.utoronto <520CCA41.3000107"@cs.utoronto.ca>
[not found] ` <520D089A.1020806@cornell.edu>
[not found] ` <83ioz6op5v.fsf@gnu.org>
[not found] ` <520D4036.8010303@cs.utoronto.ca>
[not found] ` <8361v6nhdb.fsf@gnu.org>
2013-08-16 11:37 ` 64-bit emacs crashes a lot Ryan Johnson
2013-08-16 13:10 ` Eli Zaretskii
[not found] ` <520D900A.8000907@cornell.edu>
[not found] ` <520DABDC.8020304@cs.utoronto.ca>
[not found] ` <520DBFCD.4080808@cs.utoronto.ca>
[not found] ` <8338qangma.fsf@gnu.org>
2013-08-16 11:39 ` Ryan Johnson
[not found] ` <834naqnh9t.fsf@gnu.org>
2013-08-16 11:41 ` Ryan Johnson
2013-08-16 13:31 ` Eli Zaretskii
2013-08-16 14:16 ` Ryan Johnson
2013-08-16 14:49 ` Eli Zaretskii
2013-08-16 14:20 ` Ken Brown
2013-08-16 14:24 ` Ryan Johnson
2013-08-16 15:03 ` Eli Zaretskii
2013-08-16 15:45 ` Eli Zaretskii
2013-08-16 16:51 ` Ryan Johnson [this message]
2013-08-16 17:46 ` Ken Brown
[not found] ` <520E5D71.3020307@cornell.edu>
2013-08-16 17:24 ` Ryan Johnson
2013-08-16 18:55 ` Ken Brown
2013-08-16 19:37 ` Eli Zaretskii
2013-08-16 20:17 ` Eli Zaretskii
2013-08-16 20:33 ` Ken Brown
2013-08-16 21:20 ` Ryan Johnson
2013-08-17 7:01 ` Eli Zaretskii
2013-08-17 12:17 ` Ken Brown
2013-08-17 19:43 Angelo Graziosi
2013-08-17 20:16 ` Ken Brown
2013-08-17 22:23 ` Angelo Graziosi
2013-08-18 17:43 ` Ken Brown
2013-08-18 19:10 ` Angelo Graziosi
2013-08-18 19:14 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520E58AD.6050905@cs.utoronto.ca \
--to=ryan.johnson@cs.utoronto.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=kbrown@cornell.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).