This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: 64-bit emacs crashes a lot
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>
- Cc: cygwin at cygwin dot com
- Date: Fri, 16 Aug 2013 12:13:01 +0300
- Subject: Re: 64-bit emacs crashes a lot
- 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>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
Please move this discussion to emacs-devel@gnu.org.
> Date: Fri, 16 Aug 2013 01:59:41 -0400
> From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
>
> 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 <regex_compile+34482>: cmpq $0x0,0x3f8(%rbp)
> > 0x0000000100535d02 <regex_compile+34490>: je 0x100535eca
> > <regex_compile+34946>
> > 0x0000000100535d08 <regex_compile+34496>: mov 0x3f8(%rbp),%rax
> > => 0x0000000100535d0f <regex_compile+34503>: movzbl (%rax),%eax
> > 0x0000000100535d12 <regex_compile+34506>: movzbl %al,%eax
> > 0x0000000100535d15 <regex_compile+34509>: lea 0x1(%rax),%rdx
> > 0x0000000100535d19 <regex_compile+34513>: mov 0x3f8(%rbp),%rax
> > 0x0000000100535d20 <regex_compile+34520>: add %rdx,%rax
> > 0x0000000100535d23 <regex_compile+34523>: cmp %rbx,%rax
> > 0x0000000100535d26 <regex_compile+34526>: jne 0x100535eca
> > <regex_compile+34946>
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
> > <searchbufs+2912>, 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
> > <search_regs>, 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