Opened 21 months ago

Closed 2 months ago

#7134 closed bug (fixed)

ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32

Reported by: cetinsert Owned by: thoughtpolice
Priority: highest Milestone: 7.8.1
Component: GHCi Version: 7.8.1-rc1
Keywords: R_X86_64_PC32 Cc: bos@…, hvr, idhameed@…
Operating System: Windows Architecture: x86_64 (amd64)
Type of failure: GHCi crash Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

I downloaded ghc-7.6.0.20120810-x86_64-windows.exe and attempting to run GHCi dumps the following error message:

C:\Users\Cetin>ghci
GHCi, version 7.6.0.20120810: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error: R_X86_64_PC32: Hig
h bits are set in 7f9585f95a0 for WaitForSingleObject
    (GHC version 7.6.0.20120810 for x86_64_unknown_mingw32)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Tested on Windows 8 Release Preview 64-bit.

Attachments (5)

ghc-7.6.3-w64fix.patch (1.5 KB) - added by awson 3 months ago.
ghc-7.6.3-w64fix2.patch (5.4 KB) - added by awson 3 months ago.
ghc-w64fix.patch (12.7 KB) - added by awson 3 months ago.
7134amendment.patch (1.9 KB) - added by awson 3 months ago.
7134final.patch (1.8 KB) - added by awson 3 months ago.

Download all attachments as: .zip

Change History (67)

comment:1 Changed 21 months ago by pcapriotti

  • Difficulty set to Unknown
  • Milestone set to 7.6.1
  • Version set to 7.6.1-rc1

comment:2 Changed 21 months ago by pcapriotti

Thanks for the report.

comment:3 Changed 21 months ago by igloo

  • Milestone changed from 7.6.1 to 7.8.1
  • Priority changed from normal to highest

This works for me, on Windows 7 64bit.

As it only affects ghci, probably only on Windows 8, and isn't a regression (as Win64 wasn't supported at all before) I've milestoned it for 7.8.

comment:4 Changed 20 months ago by simonmar

  • Milestone changed from 7.8.1 to 7.6.2

Given that it appears to kill GHCi completely on this platform, I think 7.6.2 would be a better milestone.

comment:5 Changed 20 months ago by igloo

  • Blocked By 3658 added

comment:6 Changed 17 months ago by igloo

  • Owner set to igloo

comment:7 Changed 17 months ago by igloo

  • Status changed from new to infoneeded

If you run

peflags --bigaddr=0 c:/ghc/ghc-7.6.1/bin/ghc.exe

then does ghci work afterwards?

comment:8 Changed 17 months ago by cetinsert

I would like to test this but cannot find anything named peflags to run.

comment:9 Changed 17 months ago by cetinsert

Would it be possible to put the ghc binary that results from peflags --bigaddr=0 online, then I could download and report back immediately?
Or the peflags binary itself at least.

comment:10 Changed 17 months ago by igloo

Thanks cetinsert. I've put the bigaddr=0 version of the ghc.exe from the 7.6.1 release here:
http://www.haskell.org/ghc/dist/tmp/peflags-7.6.1/

comment:11 Changed 17 months ago by cetinsert

Sorry TRAC kept saying “error: database is locked” so I had to try contacting you by email.

Good news, GHCI runs successfully without any errors when I use the binary you uploaded!

Thanks a lot for fixing this issue! Looking forward to 7.6.2!

Screenshot: http://snag.gy/cey48.jpg
http://snag.gy/cey48.jpg

comment:12 follow-up: Changed 17 months ago by awson

  • Status changed from infoneeded to new

But after this "fix" ghc is unable to use more than 2GB of memory, AFAIK.

comment:13 in reply to: ↑ 12 Changed 17 months ago by igloo

  • Milestone changed from 7.6.2 to 7.8.1

Thanks for testing. Fixed in 7.6 by:

commit 418a8c926703ac284f7b1a39900722efa02d0834
Author: Ian Lynagh <igloo@earth.li>
Date:   Sun Dec 2 14:48:20 2012 +0000

    On Win64, mark executables as not supporting bigaddr; fixes #7134

    This is a kludge, and means that ghc/haddock won't be able to use
    more than 2G of RAM. But it'll make sure that ghci works in the short
    term while we work on a proper fix.

Replying to awson:

But after this "fix" ghc is unable to use more than 2GB of memory, AFAIK.

Yes, hopefully we'll have a better fix for 7.8.

comment:14 Changed 16 months ago by simonmar

Also reported in #7568.

comment:15 Changed 16 months ago by bos

  • Cc bos@… added

comment:16 Changed 15 months ago by morabbin

Is this a dup of #7357? For the record, I see this same linker error when building cabal-dev HEAD with 7.6.1 on Windows 8:

...
[ 8 of 19] Compiling Distribution.Dev.CabalInstall ( src\Distribution\Dev\CabalInstall.hs, dist\build\cabal-dev\cabal-dev-tmp\Distribution\Dev\CabalInstall.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc.exe: internal error: R_X86_64_PC32: High bits are set in 7fa7fcb95a0 for WaitForSingleObject
    (GHC version 7.6.1 for x86_64_unknown_mingw32)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
cabal.exe: Error: some packages failed to install:
cabal-dev-0.9.1 failed during the building phase. The exception was:
ExitFailure 255

comment:17 Changed 15 months ago by simonmar

#7357 is already closed as a dup of this one.

comment:18 Changed 14 months ago by gmainland

I am seeing the same error on Win8 x64 with GHC 7.6.2 (x64).

$ cabal install language-c-quote
Resolving dependencies...
[1 of 1] Compiling Main             ( C:\Users\gmainlan\AppData\Local\Temp\language-c-quote-0.4.4-5516\language-c-quote-0.4.4\Setup.hs, C:\Users\gmainlan\AppData\Local\Temp\language-c-quote-0.4.4-5516\language-c-quote-0.4.4\dist\setup\Main.o )
Linking C:\Users\gmainlan\AppData\Local\Temp\language-c-quote-0.4.4-5516\language-c-quote-0.4.4\dist\setup\setup.exe ...
Configuring language-c-quote-0.4.4...
Building language-c-quote-0.4.4...
Preprocessing library language-c-quote-0.4.4...
unused terminals: 4
[ 1 of 15] Compiling Language.C.Syntax ( Language\C\Syntax.hs, dist\build\Language\C\Syntax.o )
[ 2 of 15] Compiling Language.C.Parser.Tokens ( Language\C\Parser\Tokens.hs, dist\build\Language\C\Parser\Tokens.o )
[ 3 of 15] Compiling Language.C.Parser.Monad ( Language\C\Parser\Monad.hs, dist\build\Language\C\Parser\Monad.o )
[ 4 of 15] Compiling Language.C.Parser.Lexer ( dist\build\Language\C\Parser\Lexer.hs, dist\build\Language\C\Parser\Lexer.o )
[ 5 of 15] Compiling Language.C.Pretty ( Language\C\Pretty.hs, dist\build\Language\C\Pretty.o )
[ 6 of 15] Compiling Language.C.Parser.Parser ( dist\build\Language\C\Parser\Parser.hs, dist\build\Language\C\Parser\Parser.o )
[ 7 of 15] Compiling Language.C.Parser ( Language\C\Parser.hs, dist\build\Language\C\Parser.o )
[ 8 of 15] Compiling Language.C.Quote.Base ( Language\C\Quote\Base.hs, dist\build\Language\C\Quote\Base.o )
[ 9 of 15] Compiling Language.C.Quote ( Language\C\Quote.hs, dist\build\Language\C\Quote.o )
[10 of 15] Compiling Language.C.Quote.C ( Language\C\Quote\C.hs, dist\build\Language\C\Quote\C.o )
[11 of 15] Compiling Language.C.Smart ( Language\C\Smart.hs, dist\build\Language\C\Smart.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package syb-0.3.7 ... linking ... done.
Loading package symbol-0.1.4 ... linking ... done.
Loading package srcloc-0.3.0 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package text-0.11.2.3 ... linking ... done.
Loading package mainland-pretty-0.2.5 ... linking ... done.
Loading package Win32-2.3.0.0 ... linking ... ghc.exe: internal error: R_X86_64_PC32: High bits are set in 7fcaf075d29 for DefDlgProcW
    (GHC version 7.6.2 for x86_64_unknown_mingw32)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Failed to install language-c-quote-0.4.4
cabal.exe: Error: some packages failed to install:
language-c-quote-0.4.4 failed during the building phase. The exception was:
ExitFailure 3

comment:19 Changed 14 months ago by bezirg

I also have the same error on Win8 x64 with GHC 7.6.1 x64 and GHC 7.6.2 x64. I suggest using for now the x86 version bundle of GHC 7.6.1, which works fine on Win8x64.

comment:20 Changed 9 months ago by awson

So, we have Win64 GHC completely broken on Windows 8 and semi-broken on Windows 7.

Ian, since you leave GHC HQ, could you, please, clarify if you intend to fix this or describe more or less precisely realistic ways for somebody else to fix this.

comment:21 Changed 9 months ago by igloo

I think that the best way forward would be to enable DynamicGhcPrograms by default on Windows.

comment:22 Changed 9 months ago by igloo

  • Owner igloo deleted

comment:23 Changed 9 months ago by awson

Enabling DynamicGhcPrograms makes ghci work, but again, since -dynamic-too does not work on Windows it's impossible to build any libraries for ghci using Cabal (it uses dynamic-too flag to build shared libraries), because the libraries built this way lack dyn_hi interface files.

What one have to do further to get working ghc on Win64? Fix dynamic-too for windows? Or introduce some workaround into Cabal to make it not to use 'dynamic-too' when building shared libraries on Windows?

comment:24 Changed 9 months ago by igloo

Ah, compiler/main/DynFlags.hs should be changed so that

    ("Support dynamic-too",         "YES"),

is NO on Windows. Then Cabal should do the right thing.

comment:25 Changed 9 months ago by igloo

Hmm, actually, I think that using -dynamic-too on Windows ought to work, but just always use the slow path. I'm afraid I can't remember if I pushed patches to make that the case, though.

comment:26 Changed 9 months ago by awson

The last commits regarding dynamic-too on Windows are from May 25:

  1. Revert "Fix -dynamic-too on Windows"

https://github.com/ghc/ghc/commit/2ea79ab7bc4f24cce25e3b1b1029f177ae1875d1

  1. Don't try to use -dynamic-too on Windows

https://github.com/ghc/ghc/commit/20d8e8c3e15c9d559db32c2ce1e9caf31572e5d8.

Perhaps the second was intended to do this, but it looks it is insufficient for this.

comment:27 Changed 9 months ago by awson

Btw, setting "Support dynamic-too" to "NO" on Windows does the trick, thanks.

comment:28 Changed 7 months ago by ezyang

Igloo: "I'm afraid I can't remember if I pushed patches to make that the case, though." As in, the patches exist but are not pushed, or the feature is not implemented?

comment:29 Changed 7 months ago by igloo

If they aren't pushed, then they don't exist. 20d8e8c3e15c9d559db32c2ce1e9caf31572e5d8 looks like it should do the job, though.

comment:30 Changed 7 months ago by thoughtpolice

  • Cc hvr added
  • Owner set to thoughtpolice

comment:31 Changed 5 months ago by ihameed

  • Cc idhameed@… added

comment:32 Changed 3 months ago by Austin Seipp <austin@…>

In 4af1e76c701a7698ebd9b5ca3fb1394dd8b56c8d/ghc:

Add Windows to NoSharedLibsPlatformList

We're punting on full -dynamic and -dynamic-too support for Windows
right now, since it's still unstable. Also, ensure "Support dynamic-too"
in `ghc --info` is set to "NO" for Cabal.

See issues #7134, #8228, and #5987

Signed-off-by: Austin Seipp <austin@well-typed.com>

comment:33 Changed 3 months ago by awson

This patch makes static built win64 GHC 7.6.3 work. I think this patch will apply cleanly to HEAD too.

comment:34 Changed 3 months ago by awson

  • Status changed from new to patch

comment:35 Changed 3 months ago by awson

Also we can now get rid of bigaddr=0 ugly hack for 7.6. HEAD does not contain it anyway.

Changed 3 months ago by awson

comment:36 Changed 3 months ago by simonmar

Great work! I wonder whether it might be better to allocate a single space for the trampolines like we do for other platforms (see ocAllocateSymbolExtras), rather than a separate allocation for each symbol.

Do these allocations ever get freed again? See freeObjectCode.

Neither of these is a blocker, if this makes GHCi work we should just get it in and make tickets for remaining issues.

comment:37 Changed 3 months ago by awson

These allocations are not freed.

I don't know Linker.c perfectly yet. From what I saw, I've got am impression there are some other things which are not freed and I've decided to ignore this for a while to be in time for 7.8, because it is too painful to not have working GHC for 64-bit windows (not only we have no repl, we also have no any (indirectly)TH-dependent code i.e. we have virtually nothing nontrivial except GHC itself :) at all).

But thanks for references! I'll look into them and will try to make things better.

Last edited 3 months ago by awson (previous) (diff)

comment:38 follow-up: Changed 3 months ago by awson

I've learned Linker.c a bit further and found that it's entirely possible to use SymbolExtra structure and SymbolExtra *symbol_extras pointer in ObjectCode structure, which are both defined but not used under mingw32 and are used on unixish systems for almost the same purposes.

Hence, the question: am I allowed to reuse them in PEi386-related code but in a slightly different way than it is on unixish systems?

Edit:
Perhaps, reusing SymbolExtra *symbol_extras pointer in ObjectCode structure is not such a good idea, because in current code lookupSymbol is used in haskell object-linking code and calls lookupSymbolInDLLs directly. Thus we probably should make a trampoline for every "far" symbol, imported from DLL, as is now in my patch.

Last edited 3 months ago by awson (previous) (diff)

comment:39 in reply to: ↑ 38 Changed 3 months ago by simonmar

Replying to awson:

Edit:
Perhaps, reusing SymbolExtra *symbol_extras pointer in ObjectCode structure is not such a good idea, because in current code lookupSymbol is used in haskell object-linking code and calls lookupSymbolInDLLs directly. Thus we probably should make a trampoline for every "far" symbol, imported from DLL, as is now in my patch.

I don't understand this, could you explain more? Surely it should be fine to return a 64-bit pointer from lookupSymbol?

comment:40 follow-up: Changed 3 months ago by awson

If we leave lookupSymbol unmodified then address of "far" symbol, imported from DLL, and returned by lookupSymbol is different from trampoline address. Is this ok? Or do I completely misunderstand the picture?

Last edited 3 months ago by awson (previous) (diff)

comment:41 in reply to: ↑ 40 Changed 3 months ago by simonmar

Replying to awson:

If we leave lookupSymbol unmodified then address of "far" symbol, imported from DLL, and returned by lookupSymbol is different from trampoline address. Is this ok? Or do I completely misunderstand the picture?

That should be fine. Callers of lookupSymbol probably want the real address, not a newly allocated trampoline. If we allocated a trampoline for every call to lookupSymbol, we would have a problematic memory leak.

comment:42 Changed 3 months ago by awson

I've created a new patch. It is made against 7.6.3 and I think the port to HEAD should be straightforward.

  1. I reuse oc->symbol_extras;
  2. Memory for trampolines is allocated in the single shot;
  3. This memory can handily be freed in freeObjectCode (in HEAD, we have no freeObjectCode in 7.6.3);
  4. Fixed bug when trampolined symbols were not added to symbol hash table.

If the patch is accepted I'll port it to HEAD.

Changed 3 months ago by awson

comment:43 Changed 3 months ago by simonmar

One thing worries me about this patch: isn't it possible that VirutalAlloc will give you some memory that is more than a 32-bit offset away from the source of the jump, which would mean that your trampoline would be too far away?

comment:44 Changed 3 months ago 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.

comment:45 Changed 3 months ago by awson

I've made preliminary port of this patch to HEAD. It works on my Windows 8 64-bit boxes, but some mentions should be made:

  1. I've disabled .ctor section handling. It was introduced recently and does not work on x86_64 mingw32 barfing can't find section `';
  1. It turned out STG allocator (which uses standard C malloc, which, in turn, uses HeapAlloc on Windows) can allocate some memory from high addresses. This did not occured when I allocated trampolines area with VirtualAlloc directly, but it makes Symon's concerns looks much more reasonable than I thought before. Probably, it is worth efforts to guarantee placement of trampolines area next to object image in memory as it is made in unixish code. Especially because we now allocate trampolines for all externs and not only for undefined externs (which accidentally was enough for 7.6.3) precisely because of STG allocator puts some *defined* externs to high addresses.

Anyway, right now this patch makes x86_64 mingw32 working!

comment:46 Changed 3 months ago by simonmar

I'm happy for this to go in, but please open new tickets for the remaining issues, and document the status in the release notes.

Changed 3 months ago by awson

comment:47 Changed 3 months ago by awson

I've updated the patch for HEAD. Now:

  1. Memory for trampolines is reserved right next to memory for image. We reserve this space for all symbols in image. This could look as overkill, but this is the way it is done in unixish cases, and also VirtualAlloc takes physical memory from system lazily (only when relevant page is accessed), and we don't need to save virtual space because we have plenty of it. Unlike in unixish cases, though, we avoid any reallocations because we can take the number of symbols from PECoff header.
  1. Loading of archives is fixed. Looking into the code I can say it never worked for static GHCi linker on Win64. Now it works. Don't try to remove prelinked HSbase-4.7.0.0.o though :) otherwise ghci segfaults trying to set buffering status for base's stdin, stdout and stderr. I suspect, this is related to the way initInterpBuffering in GhciMonad.hs works.
  1. Disabled .ctor handling comments now contain the number of related ticket, which I've created for this.
  1. The status is documented in release notes.

comment:48 Changed 3 months ago by simonmar

Looks great, thanks @awson!

comment:49 Changed 3 months ago by Austin Seipp <austin@…>

In 8f8bd88ce654828fef44378c3a4732d6941b9596/ghc:

Fix the Win64 RTS linker & disable .ctors

This fixes #7134

Signed-off-by: Austin Seipp <austin@well-typed.com>

comment:50 Changed 3 months ago by thoughtpolice

  • Blocked By 3658 removed
  • Resolution set to fixed
  • Status changed from patch to closed

Thank you Kyrill! Merged.

Changed 3 months ago by awson

comment:51 Changed 3 months ago by awson

When battling with #8717, I've found my patch has a couple of rough edges and one bug. They didn't manifest themselves, though. Please, apply this amendment patch both to 7.8 and HEAD.

Last edited 3 months ago by hvr (previous) (diff)

comment:52 Changed 3 months ago by awson

  • Owner thoughtpolice deleted
  • Resolution fixed deleted
  • Status changed from closed to new

comment:53 Changed 3 months ago by awson

  • Status changed from new to patch

comment:54 Changed 3 months ago by awson

  • Owner set to thoughtpolice

comment:55 Changed 3 months ago by thoughtpolice

Awesome, thank you Kyrill. I'm testing this now.

(FWIW, you will officially become "Windows Commander in Chief" soon enough if you're not careful... :)

comment:56 Changed 3 months ago by Austin Seipp <austin@…>

In fda9bebc61cab7235123b50dc70dbf30f0140dad/ghc:

Fix some edge cases in 8f8bd88c (#7134)

Signed-off-by: Austin Seipp <austin@well-typed.com>

Changed 3 months ago by awson

comment:57 Changed 3 months ago by awson

Finally ironed out the egregious bug which causes numerical segfaults here and there.

The culprit is 4179-4185 lines part (redundant ghciInsertSymbolTable). Other changes are tiny fixes (not particularly important).

This also fixes #8717. I've closed it as "invalid" then.

Please apply to 7.8 and HEAD. Thanks.

comment:58 Changed 3 months ago by Austin Seipp <austin@…>

In 2b33f6e8045fcd00f19883bb5e8895cbaf1bf81e/ghc:

Final fix to #7134 (and #8717 as well.)

Signed-off-by: Austin Seipp <austin@well-typed.com>

comment:59 Changed 3 months ago by thoughtpolice

  • Status changed from patch to merge

comment:60 Changed 3 months ago by awson

Thanks. It is merged in HEAD but still not in 7.8.

comment:61 Changed 2 months ago by thoughtpolice

  • Version changed from 7.6.1-rc1 to 7.8.1-rc1

comment:62 Changed 2 months ago by thoughtpolice

  • Resolution set to fixed
  • Status changed from merge to closed

Merged in 7.8.

Note: See TracTickets for help on using tickets.