Crash on Windows with large data

[Simon Marlow]

On 22/03/13 21:26, Jason Dagit wrote:
> I had never heard of BEX/BEX64 errors before. Naturally I wanted to know
> what it was. Perhaps others here have never heard of this as well? Just
> in case, I'll share what I learned.
>
> After a bit of digging I came across this:
> http://technet.microsoft.com/en-us/library/cc738483(WS.10).aspx
>
> I think that article is saying that windows has a policy to prevent
> arbitrary buffers from being executed. Perhaps the RTS needs to do
> something special on windows when it's allocating pages above a certain
> address?
>
> Of potential note is this section (I don't know the RTS at all, so maybe
> it already takes care of the following):
>
>
>         What works differently?
>
>
>           Application Compatibility
>
> Some application behaviors are expected to be incompatible with DEP.
> Applications that perform dynamic code generation (such as just-in-time
> code generation) and that do not explicitly mark generated code with
> Execute permission might have compatibility problems with DEP.
> Applications that are not built with SafeSEH must have their exception
> handlers located in executable memory regions.
>
> Applications that attempt to violate DEP will receive an exception with
> status code |STATUS_ACCESS_VIOLATION (0xC0000005)|. If an application
> requires executable memory, it must explicitly set this attribute on the
> appropriate memory by specifying
> |PAGE_EXECUTE|,| PAGE_EXECUTE_READ|,| PAGE_EXECUTE_READWRITE
> |or|PAGE_EXECUTE_WRITECOPY| in the memory protection argument of the
> |Virtual* |memory allocation functions. Heap allocations using the
> |malloc()| and |HeapAlloc()|functions are non-executable.
>
> Perhaps the problem is reproducible simply by forcing the 64bit windows
> build of ghc to execute a thunk allocated above the 4 GB address range?

We explicitly call VirtualProtect() to set the execute bit on pages that 
we need to execute code from, and have done for some time (Windows has 
had DEP since XP SP2).  In GHC this happens for foreign import 
"wrapper", and when compiling a foreign call with GHCi, it doesn't 
happen for ordinary thunks - the code for these is statically compiled 
into the binary.

So the bottom line is I don't know what's going wrong here, and 
unfortunately I don't have the time to investigate right now.  Perhaps 
Ian would able to look into it, as he did the Win 64 port.

Cheers,
	Simon