Re: 64-bit emacs crashes a lot

[Ryan Johnson <ryan.johnson@cs.utoronto.ca>]

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

Ryan