Re: 64-bit emacs crashes a lot

[Ryan Johnson]

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
> > > <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