From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ryan Johnson Newsgroups: gmane.emacs.devel Subject: Re: 64-bit emacs crashes a lot Date: Fri, 16 Aug 2013 12:51:57 -0400 Message-ID: <520E58AD.6050905@cs.utoronto.ca> References: <51F3151D.7040000@cs.utoronto.ca> <51F33565.1090406@cornell.edu> <51F33F52.4060405@cs.utoronto.ca> <51FB1D9E.5090102@cs.utoronto.ca> <20130802080211.GA18054@calimero.vinschen.de> <51FB9228.2020309@cornell.edu> <51FBA100.90005@cs.utoronto.ca> <51FD5462.5020400@cs.utoronto.ca> <51FFBDFF.7040501@cornell.edu> <51FFC4F2.8080909@cs.utoronto.ca> <5203D89E.6030801@cornell.edu> <5203DCCA.1010105@cs.utoronto.ca> <5205B364.8090007@cs.utoronto.ca> <52064730.50404@cornell.edu> <"52065B3C.6060104@cs.utoronto <520CCA41.3000107"@cs.utoronto.ca> <520D089A.1020806@cornell.edu> <83ioz6op5v.fsf@gnu.org> <520D4036.8010303@cs.utoronto.ca> <520D900A.8000907@cornell.edu> <834naqnh9t.fsf@gnu.org> <520E0FF8.1070709@cs.utoronto.ca> <83txipn4n4.fsf@gnu.org> <520E3510.8080101@cornell.edu> <83eh9tmyg7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1376674736 19939 80.91.229.3 (16 Aug 2013 17:38:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Aug 2013 17:38:56 +0000 (UTC) Cc: Ken Brown , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 16 19:38:57 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VANzD-0005Gi-Rg for ged-emacs-devel@m.gmane.org; Fri, 16 Aug 2013 19:38:56 +0200 Original-Received: from localhost ([::1]:60444 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VANzD-0007Ye-GS for ged-emacs-devel@m.gmane.org; Fri, 16 Aug 2013 13:38:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VANG8-000090-BH for emacs-devel@gnu.org; Fri, 16 Aug 2013 12:52:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VANFz-00077D-1D for emacs-devel@gnu.org; Fri, 16 Aug 2013 12:52:20 -0400 Original-Received: from bureau82.ns.utoronto.ca ([128.100.132.182]:54826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VANFy-000771-Sj; Fri, 16 Aug 2013 12:52:10 -0400 Original-Received: from [192.168.0.106] (76-10-140-156.dsl.teksavvy.com [76.10.140.156]) (authenticated bits=0) by bureau82.ns.utoronto.ca (8.13.8/8.13.8) with ESMTP id r7GGq3Kc015846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 12:52:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: <83eh9tmyg7.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 128.100.132.182 X-Mailman-Approved-At: Fri, 16 Aug 2013 13:38:53 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162822 Archived-At: On 16/08/2013 11:45 AM, Eli Zaretskii wrote: >> Date: Fri, 16 Aug 2013 10:20:00 -0400 >> From: Ken Brown >> CC: Ryan Johnson , 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 : push %rbp > 0x00000001006c1547 : push %rbx > 0x00000001006c1548 : sub $0x28,%rsp > 0x00000001006c154c : lea 0x80(%rsp),%rbp > 0x00000001006c1554 : mov %rcx,%rax > 0x00000001006c1557 : test %rax,%rax > 0x00000001006c155a : jne 0x1006c1566 > %rax is the variable "interval", and if non-zero we jump to +32 > 0x00000001006c155c : mov $0x0,%eax > 0x00000001006c1561 : jmpq 0x1006c1757 > > 0x00000001006c1566 : mov 0x10(%rax),%rdx > 0x00000001006c156a : test %rdx,%rdx > 0x00000001006c156d : je 0x1006c15ea > %rdx is interval->left, and if non-zero we fall through to +41 > 0x00000001006c156f : mov 0x10(%rax),%rbx > 0x00000001006c1573 : jmp 0x1006c1579 > copy interval->left into %rbx as initial value of "i" and jump into loop at +51 > 0x00000001006c1575 : mov 0x18(%rbx),%rbx loop body: set i = i->right > => 0x00000001006c1579 : mov 0x18(%rbx),%rdx > 0x00000001006c157d : test %rdx,%rdx > 0x00000001006c1580 : jne 0x1006c1575 > 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 ) 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 ) 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_from_string_func=0x100594ec8 , 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 , arg=4318413846, handlers=4307507906, hfun=0x1006af874 ) 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 , handlers=4307507906, hfun=0x10053d7bb ) 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 , 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