From: Ken Brown <kbrown@cornell.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Ryan Johnson <ryan.johnson@cs.utoronto.ca>, emacs-devel@gnu.org
Subject: Re: 64-bit emacs crashes a lot
Date: Fri, 16 Aug 2013 10:20:00 -0400 [thread overview]
Message-ID: <520E3510.8080101@cornell.edu> (raw)
In-Reply-To: <83txipn4n4.fsf@gnu.org>
On 8/16/2013 9:31 AM, Eli Zaretskii wrote:
>> Date: Fri, 16 Aug 2013 07:41:44 -0400
>> From: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
>>
>> 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 <kbrown@cornell.edu>
>>>>
>>>> 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.
Ken
next prev parent reply other threads:[~2013-08-16 14:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <51F3151D.7040000@cs.utoronto.ca>
[not found] ` <51F33565.1090406@cornell.edu>
[not found] ` <51F33F52.4060405@cs.utoronto.ca>
[not found] ` <51FB1D9E.5090102@cs.utoronto.ca>
[not found] ` <20130802080211.GA18054@calimero.vinschen.de>
[not found] ` <51FB9228.2020309@cornell.edu>
[not found] ` <51FBA100.90005@cs.utoronto.ca>
[not found] ` <51FD5462.5020400@cs.utoronto.ca>
[not found] ` <51FFBDFF.7040501@cornell.edu>
[not found] ` <51FFC4F2.8080909@cs.utoronto.ca>
[not found] ` <5203D89E.6030801@cornell.edu>
[not found] ` <5203DCCA.1010105@cs.utoronto.ca>
[not found] ` <5205B364.8090007@cs.utoronto.ca>
[not found] ` <52064730.50404@cornell.edu>
[not found] ` <"52065B3C.6060104@cs.utoronto <520CCA41.3000107"@cs.utoronto.ca>
[not found] ` <520D089A.1020806@cornell.edu>
[not found] ` <83ioz6op5v.fsf@gnu.org>
[not found] ` <520D4036.8010303@cs.utoronto.ca>
[not found] ` <8361v6nhdb.fsf@gnu.org>
2013-08-16 11:37 ` 64-bit emacs crashes a lot Ryan Johnson
2013-08-16 13:10 ` Eli Zaretskii
[not found] ` <520D900A.8000907@cornell.edu>
[not found] ` <520DABDC.8020304@cs.utoronto.ca>
[not found] ` <520DBFCD.4080808@cs.utoronto.ca>
[not found] ` <8338qangma.fsf@gnu.org>
2013-08-16 11:39 ` Ryan Johnson
[not found] ` <834naqnh9t.fsf@gnu.org>
2013-08-16 11:41 ` Ryan Johnson
2013-08-16 13:31 ` Eli Zaretskii
2013-08-16 14:16 ` Ryan Johnson
2013-08-16 14:49 ` Eli Zaretskii
2013-08-16 14:20 ` Ken Brown [this message]
2013-08-16 14:24 ` Ryan Johnson
2013-08-16 15:03 ` Eli Zaretskii
2013-08-16 15:45 ` Eli Zaretskii
2013-08-16 16:51 ` Ryan Johnson
[not found] ` <520E5D71.3020307@cornell.edu>
2013-08-16 17:24 ` Ryan Johnson
2013-08-16 18:55 ` Ken Brown
2013-08-16 19:37 ` Eli Zaretskii
2013-08-16 20:17 ` Eli Zaretskii
2013-08-16 20:33 ` Ken Brown
2013-08-16 21:20 ` Ryan Johnson
2013-08-17 7:01 ` Eli Zaretskii
2013-08-17 12:17 ` Ken Brown
2013-08-16 17:46 ` Ken Brown
2013-08-17 19:43 Angelo Graziosi
2013-08-17 20:16 ` Ken Brown
2013-08-17 22:23 ` Angelo Graziosi
2013-08-18 17:43 ` Ken Brown
2013-08-18 19:10 ` Angelo Graziosi
2013-08-18 19:14 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520E3510.8080101@cornell.edu \
--to=kbrown@cornell.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=ryan.johnson@cs.utoronto.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.