unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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




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