#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