Opened 2 years ago

Closed 2 years ago

#10563 closed bug (fixed)

GHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1

Reported by: tejon Owned by:
Priority: normal Milestone: 7.10.3
Component: Compiler (Linking) Version: 7.10.1
Keywords: Cc:
Operating System: Windows Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: #10672 Differential Rev(s):
Wiki Page:

Description

[ 4 of 11] Compiling Reflex.Dom.Internal ( src\Reflex\Dom\Internal.hs, dist\build\Reflex\Dom\Internal.o )
ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 00000000184b3978
    (GHC version 7.10.1 for x86_64_unknown_mingw32)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

This happens with unmodified reflex-dom.cabal (which specifies -funbox-strict-fields and -O2) and also with all ghc-options: flags removed and -O or -O0. When compiling with the bundled mingw it also pops up a GUI error window:

ghc.exe - Entry Point Not Found

The procedure entry point pthread_cond_timedwait_relative_np could not be located in the dynamic link library libwinpthread-1.dll.

I also tried using a fully-updated mingw64 from MSYS2, which has solved -pthread issues for me in the past, but that simply crashes with no additional message.

Verbose cabal output attached.

Attachments (1)

cabal-v.log (7.9 KB) - added by tejon 2 years ago.
cabal install -v

Download all attachments as: .zip

Change History (9)

Changed 2 years ago by tejon

Attachment: cabal-v.log added

cabal install -v

comment:1 Changed 2 years ago by tejon

Summary: GHC 7.10.1 Win7 x86_64 crash when building reflex-domGHC 7.10.1 Win7 x86_64 crash when building reflex-dom-0.1.1

comment:2 Changed 2 years ago by tejon

Type of failure: None/UnknownCompile-time crash

comment:3 Changed 2 years ago by ezyang

Hello, can you run your program with +RTS -Dl with the debug RTS and report any Unknown PEi386 section name errors? It's probably exception handling.

comment:4 Changed 2 years ago by tejon

The program in question is GHC. Is one of the standard build.mk configurations appropriate for this? I don't know if I'm dealing with stage 1 or 2, or something else here...

comment:5 Changed 2 years ago by ezyang

Yeah GhcDebugged=YES should be OK. See also #10672

comment:6 Changed 2 years ago by JohnWiegley

Component: CompilerCompiler (Linking)

comment:7 Changed 2 years ago by Thomas Miedema <thomasmiedema@…>

In 620fc6f9/ghc:

Make Windows linker more robust to unknown sections

The Windows Linker has 3 main parts that this patch changes.

1) Identification and classification of sections
2) Adding of symbols to the symbols tables
3) Reallocation of sections

1.
Previously section identification used to be done on a whitelisted
basis. It was also exclusively being done based on the names of the
sections. This meant that there was a bit of a cat and mouse game
between `GCC` and `GHC`. Every time `GCC` added new sections there was a
good chance `GHC` would break. Luckily this hasn't happened much in the
past because the `GCC` versions `GHC` used were largely unchanged.

The new code instead treats all new section as `CODE` or `DATA`
sections, and changes the classifications based on the `Characteristics`
flag in the PE header. By doing so we no longer have the fragility of
changing section names. The one exception to this is the `.ctors`
section, which has no differentiating flag in the PE header, but we know
we need to treat it as initialization data.

The check to see if the sections are aligned by `4` has been removed.
The reason is that debug sections often time are `1 aligned` but do have
relocation symbols. In order to support relocations of `.debug` sections
this check needs to be gone. Crucially this assumption doesn't seem to
be in the rest of the code. We only check if there are at least 4 bytes
to realign further down the road.

2.
The second loop is iterating of all the symbols in the file and trying
to add them to the symbols table. Because the classification of the
sections we did previously are (currently) not available in this phase
we still have to exclude the sections by hand. If they don't we will
load in symbols from sections we've explicitly ignored the in # 1. This
whole part should rewritten to avoid this. But didn't want to do it in
this commit.

3.
Finally the sections are relocated. But for some reason the PE files
contain a Linux relocation constant in them `0x0011` This constant as
far as I can tell does not come from GHC (or I couldn't find where it's
being set). I believe this is probably a bug in GAS. But because the
constant is in the output we have to handle it. I am thus mapping it to
the constant I think it should be `0x0003`.

Finally, static linking *should* work, but won't. At least not if you
want to statically link `libgcc` with exceptions support. Doing so would
require you to link `libgcc` and `libstd++` but also `libmingwex`. The
problem is that `libmingwex` also defines a lot of symbols that the RTS
automatically injects into the symbol table. Presumably because they're
symbols that it needs. like `coshf`. The these symbols are not in a
section that is declared with weak symbols support. So if we ever want
to get this working, we should either a) Ask mingw to declare the
section as such, or b) treat all a imported symbols as being weak.
Though this doesn't seem like it's a good idea..

Test Plan:
Running ./validate for both x86 and x86_64

Also running the specific test case for #10672

make TESTS="T10672_x86 T10672_x64"

Reviewed By: ezyang, thomie, austin

Differential Revision: https://phabricator.haskell.org/D1244

GHC Trac Issues: #9907, #10672, #10563

comment:8 Changed 2 years ago by thomie

Milestone: 7.10.3
Resolution: fixed
Status: newclosed

This should be fixed in the next release. See #10672. If not, please reopen.

Note: See TracTickets for help on using tickets.