Re: 64-bit emacs crashes a lot

[Ryan Johnson]

On 16/08/2013 10:20 AM, Ken Brown wrote:
> On 8/16/2013 9:31 AM, Eli Zaretskii wrote:
> > > Date: Fri, 16 Aug 2013 07:41:44 -0400
> > > From: Ryan Johnson <address@hidden>
> > >
> > > On 16/08/2013 4:58 AM, Eli Zaretskii wrote:
> > > > Again, please move this discussion to emacs-devel.
> > > Back pointer: http://cygwin.com/ml/cygwin/2013-08/msg00273.html
> > >
> > > > > Date: Thu, 15 Aug 2013 22:35:54 -0400
> > > > > From: Ken Brown <address@hidden>
> > > > >
> > > > > 1. Invoke 'emacs-nox -Q' in mintty.
> > > > >
> > > > > 2. M-x compile C-a C-k ls RET
> > > > >
> > > > > 3. C-x o
> > > > >
> > > > > 4. Hit 'g' repeatedly.
> > > > >
> > > > > I got it to abort with Fatal error 6 after slightly over 100 
> > > > > repetitions.
> > > > >
> > > > > I then tried the same thing with emacs-X11 (running under X, not in
> > > > > mintty).  I hit 'g' 200 times without a problem.  I repeated this 
> > > > > with
> > > > > emacs-w32, again 200 times without a problem.
> > > > >
> > > > > So there's a bug somewhere.  But if it's an emacs bug, it's 
> > > > > strange that
> > > > > it only occurs with emacs-nox and not with either of the GUI 
> > > > > versions of
> > > > > emacs.
> > > > I suspect that buffer relocation might be the reason.  Can you show a
> > > > backtrace from the fatal error in an unoptimized build, with the above
> > > > recipe?
> > > I'll try to get one. Meanwhile, is there a quick way to disable buffer
> > > relocation as a sanity test?
> >
> > I don't think so, but maybe it's already disabled in your build.  What
> > do you see on these two lines when configure finishes:
> >
> >    Should Emacs use a relocating allocator for buffers?    yes
> >    Should Emacs use mmap(2) for buffer allocation?         no
>
>   Should Emacs use a relocating allocator for buffers?    no
>   Should Emacs use mmap(2) for buffer allocation?         yes
>
> > In any case, you could configure with --enable-checking=all, it might
> > catch the problem earlier.
> >
> > > If the optimized build still crashes reliably without it, the real
> > > problem is probably something else.
> >
> > Maybe, but not necessarily.
>
> FWIW, I just tried this on the trunk, both with and without 
> optimization.  The bug is still there in the optimized build, but I 
> couldn't trigger it in the unoptimized build.  I've also checked that 
> the bug occurs only in 64-bit Cygwin, not 32-bit Cygwin.
>
> Here's some speculation.  On 64-bit Cygwin, the space allocated to the 
> heap and mmap goes from 0x6:00000000 to 0x700:00000000, with the heap 
> starting at the bottom and mmaps allocated from the top down.  (I've 
> added the colons for readability).  Is it possible that the optimized 
> build takes shortcuts that are somehow incompatible with this model?
>
> I'm grasping at straws here, but I'm just trying to think of things 
> that differ between the 32-bit and 64-bit systems.
I also suspect that the black magic cast by emacs and cygwin clash 
somehow for 64-bit builds... some assumption the one makes that the 
other breaks... but who knows which which assumption or which one breaks 
it.

I also cannot get the unoptimized build to crash today; I'm not sure 
what was going on yesterday that made it unstable, but the unwanted 
reboot during the night seems to have cleared up whatever it was.

Ryan