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.<div><br></div><div>After a bit of digging I came across this: <a href="http://technet.microsoft.com/en-us/library/cc738483(WS.10).aspx">http://technet.microsoft.com/en-us/library/cc738483(WS.10).aspx</a><div>
<br></div><div>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?</div>
<div><br></div><div>Of potential note is this section (I don't know the RTS at all, so maybe it already takes care of the following):</div><div><h4 class="subHeading" style="color:rgb(42,42,42);font-size:1.33em;font-family:'Segoe UI','Lucida Grande',Verdana,Arial,Helvetica,sans-serif;margin:0px">
What works differently?</h4><div class="subSection" style="font-family:'Segoe UI','Lucida Grande',Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:16px"><h5 class="subHeading" style="font-size:0.857em;font-weight:normal;line-height:15px;margin:0px">
Application Compatibility</h5><div class="subSection"><p style="color:rgb(42,42,42);margin-top:0px;margin-bottom:0px;padding-bottom:15px;line-height:18px">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.</p>
<p style="color:rgb(42,42,42);margin-top:0px;margin-bottom:0px;padding-bottom:15px;line-height:18px">Applications that attempt to violate DEP will receive an exception with status code <code>STATUS_ACCESS_VIOLATION (0xC0000005)</code>. If an application requires executable memory, it must explicitly set this attribute on the appropriate memory by specifying <code>PAGE_EXECUTE</code>,<code> PAGE_EXECUTE_READ</code>,<code> PAGE_EXECUTE_READWRITE </code>or<code>PAGE_EXECUTE_WRITECOPY</code> in the memory protection argument of the <code>Virtual* </code>memory allocation functions. Heap allocations using the <code>malloc()</code> and <code>HeapAlloc()</code>functions are non-executable.</p>
</div></div>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?</div><div><br></div><div><br><div class="gmail_quote">On Fri, Mar 22, 2013 at 6:55 AM, Simon Peyton-Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yitz and others<br>
<br>
| Would you and your team be interested in looking at this?<br>
<br>
In principle yes of course. I wish we had a "team", as in a bunch of people whose job it is to make GHC fantastic. However we certainly do have a team of volunteers who do amazing things; and one (totally heroic and overworked) Ian Lynagh who really does have it as his job. So in practice it might be harder.<br>
<br>
Does anyone feel able to help Yitz?<br>
<br>
Ian might, depending on how hard it was to put him into a position where he could reproduce it. Plus it depends on how critical it is for you.<br>
<br>
Simon<br>
<br>
| -----Original Message-----<br>
| From: <a href="mailto:sefer.org@gmail.com">sefer.org@gmail.com</a> [mailto:<a href="mailto:sefer.org@gmail.com">sefer.org@gmail.com</a>] On Behalf Of<br>
| Yitzchak Gale<br>
| Sent: 21 March 2013 21:03<br>
| To: Simon Peyton-Jones<br>
| Subject: Crash on Windows with large data<br>
|<br>
| Hi Simon,<br>
|<br>
| At work, we have an app that ran into a BEX64 crash on Windows when<br>
| processing a large and complex data set. I compiled a special version of<br>
| our app with GHC 7.6.2 for Windows, because we suspect it needs to run<br>
| on 64 bits.<br>
|<br>
| On Linux, the same app compiled with 7.4.2 runs to completion when<br>
| processing the same data, although it does use as much as 15 GB of<br>
| memory in the process. The Windows version crashed when it hit something<br>
| over 5 GB or memory usage.<br>
|<br>
| Would you and your team be interested in looking at this?<br>
|<br>
| The problem is, both our app and our customer's data is proprietary.<br>
| The customer is a well-know very large corporation. Due to the nature of<br>
| the problem, I doubt there is any reasonable way to isolate the problem.<br>
| I imagine we would need to send you the original code and data. Is there<br>
| some sort of arrangement that can be made for this situation?<br>
|<br>
| Thanks,<br>
| Yitz<br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div></div>