On 19/08/2013 5:32 AM, Corinna Vinschen wrote:
On Aug 16 16:49, Ken Brown wrote:
The problem that has been discussed at length in the thread "64-bit
emacs crashes a lot" appears to have been solved on the emacs-devel
list. (I say "appears to" because I'm waiting for Ryan to confirm
this.) The problem went away for me when I built emacs with
'LDFLAGS=-Wl,--stack,4194304'. I'm wondering if it's just that
emacs needs an unusually big stack or if the default stack size on
64-bit Cygwin should be increased for all applications.
I noticed that ulimit -s gives 2025 on both 32-bit Cygwin and 64-bit
Cygwin. Shouldn't 64-bit applications need a larger stack than
32-bit applications in general?
From my POV, if you have a stack-active application, just add the
aforementioned --stack linker option, or call peflags -x after the
build. The latter can be done any time
FYI, I just tried upping the stack size on /usr/bin/emacs-nox, but it
still crashes. Most likely because the damage was already done during
bootstrap, when it has much larger memory requirements than normal.
Still no crashes so far in the version I linked with --stack, though.
One thing I don't understand, though: shouldn't a stack overflow
normally manifest as a seg fault when trying to access the invalid
addresses, rather than silent memory corruption?
However, /proc/pid/maps for emacs shows:
00010000-00020000 rw-s 00000000 0000:0000 0 [win
heap 1 default shared]
00020000-00030000 rw-s 00000000 0000:0000 0 [win heap 2 default shared]
00030000-001E4000 ===p 00000000 0000:0000 0 [stack (tid 4896)]
001E4000-001E6000 rw-g 001B4000 0000:0000 0 [stack (tid 4896)]
001E6000-00230000 rw-p 001B6000 0000:0000 0 [stack (tid 4896)]
GDB reports that thread 4896 is the main thread... so I guess Windows
doesn't reserve a red zone around its stack, but instead chooses to
place the main thread stack right next to the fully-mapped global
shared heap to maximize the potential for Fun?
Windows only uses reserved but only partially committed memory for its stacks. In order to detect when to
commit more stack, it installs a one-shot guard page (btw the same type of guard page that is used for the
hotspot yellow and red zone) right at the edge of the currently commited stack zone. When a thread accesses
this guard page an exception is thrown which Windows catches internally, commits more stack and
re-establishes the one-shot guard page at the new edge of the commited zone. When Windows detects such an
exception inside the _last 4 pages_ of a stack (I couldn't find any documentation for that on MSDN, I found
this value from manually testing on several Windows machines with 4k stack pages) it throws a STACK_OVERFLOW_EXCEPTION.