64-bit emacs crashes a lot
Eli Zaretskii
eliz@gnu.org
Fri Aug 16 09:12:00 GMT 2013
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
More information about the Cygwin
mailing list