[GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32

[GHC]

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
-------------------------------+----------------------------------
        Reporter:  cetinsert   |            Owner:  thoughtpolice
            Type:  bug         |           Status:  patch
        Priority:  highest     |        Milestone:  7.8.1
       Component:  GHCi        |          Version:  7.6.1-rc1
      Resolution:              |         Keywords:  R_X86_64_PC32
Operating System:  Windows     |     Architecture:  x86_64 (amd64)
 Type of failure:  GHCi crash  |       Difficulty:  Unknown
       Test Case:              |       Blocked By:  3658
        Blocking:              |  Related Tickets:
-------------------------------+----------------------------------

Comment (by awson):

 In theory, it's possible.

 There is even a comment in my code exactly about this. I'll cite it here:
 "Unlike in unixish case we don't bother to guarantee extras are laid out
 next to object image in memory. It looks Windows allocator don't suddenly
 want to allocate memory from top to down if we don't tell him so. And we
 don't."

 {{{VirtualAlloc}}} has a special flag {{{MEM_TOP_DOWN}}} which according
 to http://msdn.microsoft.com/en-
 us/library/windows/desktop/aa366887%28v=vs.85%29.aspx: "Allocates memory
 at the highest possible address". Without this flag it (as I tested)
 allocates memory "not far away from here". I agree this is not a strong
 guarantee, but, as of now, all works perfectly. Also,
 {{{VirtualAlloc}}}'ed ({{{oc->image}}} is allocated with
 {{{VirtualAlloc}}}) memory can't be reallocated without explicit new
 allocation and data copying.

 Sure, it won't take much to implement all this, but I just can't bring
 myself to do it right now.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:44>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler