On Aug 19 07:04, Ryan Johnson wrote:
On 19/08/2013 6:49 AM, Ryan Johnson wrote:
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?
That would be helpful.
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?
Right. I have no idea what the two shared mem regions preceeding the
stack are good for, though.
Some googling turns up
http://comments.gmane.org/gmane.comp.java.openjdk.hotspot.runtime.devel/7706
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.
So maybe emacs just had the incredibly bad luck to alloca() a large
buffer right at end-of-stack and then somehow managed to skip over
the 4 guard pages when accessing it?
That's unlikely since alloca is designed to probe the stack in 4K
steps. And STATUS_STACK_OVERFLOW is translated to a SEGV by Cygwin's
exception handler.