#7207 closed bug (duplicate)

linker fails to load package with binding to foreign library (win64)

Reported by: nus Owned by:
Priority: normal Milestone: 7.8.1
Component: GHCi Version: 7.6.1-rc1
Keywords: Cc:
Operating System: Windows Architecture: x86_64 (amd64)
Type of failure: GHCi crash Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets: #7097 #7134 #7040

Description

GHCI is unable to load some packages on Win64, the examples are given for the ansi-terminal and network packages.
The versions:

$ ghci --version
The Glorious Glasgow Haskell Compilation System, version 7.6.0.20120810
$ ghc-pkg.exe list ansi-terminal
c:/mnt/data1/ghc-7.6.0.20120810\lib\package.conf.d:
    ansi-terminal-0.5.5
$ ghc-pkg.exe list network
c:/mnt/data1/ghc-7.6.0.20120810\lib\package.conf.d:
    network-2.3.1.0

The failures:

$ 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 ... done.
Prelude> import System.Console.ANSI
Prelude System.Console.ANSI> Black
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.0 ... linking ... done.
Loading package Win32-2.3.0.0 ... linking ... done.
Loading package ansi-terminal-0.5.5 ... linking ... <interactive>: internal error: R_X86_64_PC32: High bits are set in 7fefbc8ebf2 for _get_osfhandle
    (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.
$ 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 ... done.
Prelude> import Network
Prelude Network> listenOn (PortNumber 2222)
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.0 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-0.11.2.3 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package network-2.3.1.0 ... linking ... <interactive>: internal error:
_X86_64_PC32: High bits are set in 7fef7d8b47a for setsockopt
    (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.

Change History (5)

comment:1 Changed 20 months ago by nus

Backtracing the first failure:

Breakpoint 16, barf (
    s=0x24d54a0 "R_X86_64_PC32: High bits are set in %zx for %s")
    at rts\RtsMessages.c:41
41        va_start(ap,s);
(gdb) bt
#0  barf (s=0x24d54a0 "R_X86_64_PC32: High bits are set in %zx for %s")
    at rts\RtsMessages.c:41
#1  0x0000000002103ced in ocResolve_PEi386 (oc=0x6abb270) at rts\Linker.c:3938
#2  0x000000000210201d in resolveObjs () at rts\Linker.c:2608
[...snip...]
(gdb) up
#1  0x0000000002103ced in ocResolve_PEi386 (oc=0x6abb270) at rts\Linker.c:3938
3938                           barf("R_X86_64_PC32: High bits are set in %zx for
 %s",
(gdb) info locals
v = 8791724452850
sym = 0x286ffba
reltab_j = 0x2861f40
sectab_i = 0x2840018
reltab = 0x285fe20
secname = 0x6ac8160 ""
hdr = 0x2840004
sectab = 0x2840018
symtab = 0x286bb62
strtab = 0x2871868 "=£\001"
A = 0
S = 8791766694568
pP = 0x2848eb2
i = 0
j = 848
noRelocs = 3313
symbol = "_get_osfhandle", '\000' <repeats 985 times>


rts/Linker.c:

ocResolve_PEi386 ( ObjectCode* oc )
[...snip...]
         if (sym->StorageClass == MYIMAGE_SYM_CLASS_STATIC) {
[...snip...]
         } else {
            copyName ( sym->Name, strtab, symbol, 1000-1 );
            S = (size_t) lookupSymbol( (char*)symbol );
[...snip...]
            case 4: /* R_X86_64_PC32 */
               {
                   intptr_t v;
                   v = ((intptr_t)S) + ((intptr_t)(Int32)A) - ((intptr_t)pP) - 4;
                   if ((v >> 32) && ((-v) >> 32)) {
                       copyName ( sym->Name, strtab, symbol, 1000-1 );
                       barf("R_X86_64_PC32: High bits are set in %zx for %s",
                            v, (char *)symbol);
                   }
void *
lookupSymbol( char *lbl )
[...snip...]
#       elif defined(OBJFORMAT_PEi386)
        void* sym;

        sym = lookupSymbolInDLLs((unsigned char*)lbl);
        if (sym != NULL) { return sym; };
static void *
lookupSymbolInDLLs ( UChar *lbl )
[...snip...]
        sym = GetProcAddress(o_dll->instance, (char*)lbl);

Back to the trace:

Breakpoint 8, lookupSymbolInDLLs (lbl=0x22d700 "_get_osfhandle")
    at rts\Linker.c:3292
[...snip...]
3307            sym = GetProcAddress(o_dll->instance, (char*)lbl);
(gdb) n
3308            if (sym != NULL) {
(gdb) n
3310                return sym;
(gdb) info locals
o_dll = 0x3f5e650
sym = 0x7fefe217aa8
(gdb) print o_dll->name
$78 = (
    pathchar *) 0x3f5e6a0 L"\155\163\166\143\162", <incomplete sequence \164>
(gdb) p/c (wchar_t [7])*(o_dll->name)
$79 = {109 'm', 115 's', 118 'v', 99 'c', 114 'r', 116 't', 0 '\000'}

GetProcAddress is returning 0x7fefe217aa8 -- the address of _open_osfhandle in msvcrt.dll which has already been loaded by the time ansi-terminal is loading. There are 0x9f000 bytes of C:\Windows\System32\msvcrt.dll mapped into the ghc process at the load address 0x7fefe210000.
The situation with the network package is similar.
So far this stems from the same problem as in #7040 -- operations with pointers to the memory regions beyond the limits of the small C code model.

comment:2 Changed 20 months ago by igloo

  • Blocked By 3658 added

comment:3 Changed 18 months ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 7.8.1

Thanks for the report.

This would almost certainly be fixed by making ghci use dynamic libraries, but we don't know how to do that on Windows yet.

comment:4 Changed 15 months ago by bos

  • Blocked By 3658 removed

comment:5 Changed 15 months ago by bos

  • Resolution set to duplicate
  • Status changed from new to closed

Dup of #7134.

Note: See TracTickets for help on using tickets.