X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:subject:in-reply-to:to:cc:reply-to :message-id:references; q=dns; s=default; b=IukNy2ozVd34SDCdl5V3 7yoSmIlOMwXtPKSRV/woDv6Hi6EzuhUWozhITwab18K31AASIDOhDAkbRNxjfPTT AQgTSYbRkpP5zuQ04XMrCC2nVYcQ6uzIqKvVJekUr6YVvTC1ytC/CHI5KD63U1GP eyupvC7v8wV1RX6ygzeBAdE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:subject:in-reply-to:to:cc:reply-to :message-id:references; s=default; bh=kzY+9qWCr5zOZMnoK8d/UJ9cOz U=; b=mOzKj9brJbmdWgL3/1UhfSyfc9FEHtwmxWcu/iAYO02tXkBgvkEO3KNufJ NHIYi6NBioXfv2mmQ2jED/ax3uPqkRYUwRyXFfcojNd+TkuB+WDrzwM4In/7ia0A TORQCKj09snGOekCDRUHw97i1F5DOjwWYNJtCSrc28WQI1ddM= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_20,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL autolearn=no version=3.3.2 Date: Fri, 16 Aug 2013 12:13:01 +0300 From: Eli Zaretskii Subject: Re: 64-bit emacs crashes a lot In-reply-to: <520DBFCD.4080808@cs.utoronto.ca> To: Ryan Johnson Cc: cygwin AT cygwin DOT com Reply-to: Eli Zaretskii Message-id: <8338qangma.fsf@gnu.org> References: <51F3151D DOT 7040000 AT cs DOT utoronto DOT ca> <51F33565 DOT 1090406 AT cornell DOT edu> <51F33F52 DOT 4060405 AT cs DOT utoronto DOT ca> <51FB1D9E DOT 5090102 AT cs DOT utoronto DOT ca> <20130802080211 DOT GA18054 AT calimero DOT vinschen DOT de> <51FB9228 DOT 2020309 AT cornell DOT edu> <51FBA100 DOT 90005 AT cs DOT utoronto DOT ca> <51FD5462 DOT 5020400 AT cs DOT utoronto DOT ca> <51FFBDFF DOT 7040501 AT cornell DOT edu> <51FFC4F2 DOT 8080909 AT cs DOT utoronto DOT ca> <5203D89E DOT 6030801 AT cornell DOT edu> <5203DCCA DOT 1010105 AT cs DOT utoronto DOT ca> <5205B364 DOT 8090007 AT cs DOT utoronto DOT ca> <52064730 DOT 50404 AT cornell DOT edu> <"52065B3C DOT 6060104 AT cs DOT utoronto <520CCA41.3000107"@cs.utoronto.ca> <520D089A DOT 1020806 AT cornell DOT edu> <83ioz6op5v DOT fsf AT gnu DOT org> <520D4036 DOT 8010303 AT cs DOT utoronto DOT ca> <520D900A DOT 8000907 AT cornell DOT edu> <520DABDC DOT 8020304 AT cs DOT utoronto DOT ca> <520DBFCD DOT 4080808 AT cs DOT utoronto DOT ca> Please move this discussion to emacs-devel AT gnu DOT org. > 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? > 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? -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple