[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64-bit emacs crashes a lot

From: Ryan Johnson
Subject: Re: 64-bit emacs crashes a lot
Date: Fri, 16 Aug 2013 07:39:40 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

On 16/08/2013 5:13 AM, Eli Zaretskii wrote:
Please move this discussion to address@hidden
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 <address@hidden>

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
    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
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
<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-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?
I'll let you know once I hit the crash again...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]