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 07:39:40 -0400 Message-ID: <520E0F7C.6000608@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> <520DABDC.8020304@cs.utoronto.ca> <520DBFCD.4080808@cs.utoronto.ca> <8338qangma.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 1376658615 28045 80.91.229.3 (16 Aug 2013 13:10:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Aug 2013 13:10:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 16 15:10:17 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 1VAJnF-00063B-7Q for ged-emacs-devel@m.gmane.org; Fri, 16 Aug 2013 15:10:17 +0200 Original-Received: from localhost ([::1]:58865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VAJnE-0003yC-6u for ged-emacs-devel@m.gmane.org; Fri, 16 Aug 2013 09:10:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VAINl-00081n-HQ for emacs-devel@gnu.org; Fri, 16 Aug 2013 07:39:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VAINg-0003PJ-Lh for emacs-devel@gnu.org; Fri, 16 Aug 2013 07:39:53 -0400 Original-Received: from bureau83.ns.utoronto.ca ([128.100.132.183]:53682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VAINg-0003PD-Gr; Fri, 16 Aug 2013 07:39:48 -0400 Original-Received: from [192.168.0.106] (76-10-140-156.dsl.teksavvy.com [76.10.140.156]) (authenticated bits=0) by bureau83.ns.utoronto.ca (8.13.8/8.13.8) with ESMTP id r7GBdkCD006109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Aug 2013 07:39:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: <8338qangma.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 128.100.132.183 X-Mailman-Approved-At: Fri, 16 Aug 2013 09:10:12 -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:162806 Archived-At: On 16/08/2013 5:13 AM, Eli Zaretskii wrote: > Please move this discussion to emacs-devel@gnu.org. OK. For history's sake, here's the link back to the cygwin thread: http://cygwin.com/ml/cygwin/2013-08/msg00275.html >> Date: Fri, 16 Aug 2013 01:59:41 -0400 >> From: Ryan Johnson >> >> The variable pending_exact has value 0x0, which would be a Bad Thing... >> except that the code looks like this: >>> if (!pending_exact >>> >>> /* If last exactn not at current position. */ >>> => || pending_exact + *pending_exact + 1 != b >>> >> ... with corresponding assembly code looking very reasonable: >>> 0x0000000100535cfa : cmpq $0x0,0x3f8(%rbp) >>> 0x0000000100535d02 : je 0x100535eca >>> >>> 0x0000000100535d08 : mov 0x3f8(%rbp),%rax >>> => 0x0000000100535d0f : movzbl (%rax),%eax >>> 0x0000000100535d12 : movzbl %al,%eax >>> 0x0000000100535d15 : lea 0x1(%rax),%rdx >>> 0x0000000100535d19 : mov 0x3f8(%rbp),%rax >>> 0x0000000100535d20 : add %rdx,%rax >>> 0x0000000100535d23 : cmp %rbx,%rax >>> 0x0000000100535d26 : jne 0x100535eca >>> > What is the value in the RAX register at the point of the crash? Is > it also zero? Or maybe it is some other invalid pointer value? Also zero, iirc I tested it before, but my computer seems to have rebooted itself in the night and the history was lost. Unfortunately, I'm having trouble getting the debug emacs-nox to crash this morning. The -Og and -O2 builds crash even more often than before, though, usually while trying to invoke compile for the first time; the stack traces have been total garbage. I'll have to get back to you when the bug is being more cooperative... >> A third crash: >>> #1 0x0000000100541930 in re_match_2_internal (bufp=0x10095ce20 >>> , string1=0x0, size1=0, string2=0x6fffff00028 "-*- >>> mode: compilation; default-directory: \"~/\" -*-\nCompilation started >>> at Fri Aug 16 01:32:19\n\nls\n#message-20130808-090732#\t >>> emacs-crash.txt\t\tmusic\n6b8ob06a.default.tar.xz\t\t >>> emacs-nox.exe."..., size2=355, pos=254, regs=0x10095def0 >>> , stop=317) at regex.c:6217 >>> 6217 abort (); >> This time, p (the subject of the case statement) points to 0x76b3b6c7, >> which is the middle of a function (ntdll!RtlFillMemory, though the >> memory map places that address smack in the middle of kernel32.dll >> instead). This time it makes perfect sense that the switch statement >> should fail, but how did p go so wrong? > What is bufp->buffer at this point, and what is its contents? I'll let you know once I hit the crash again... Ryan