[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 10:24:25 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

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


reply via email to

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