Opened 5 years ago

Closed 4 years ago

#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 Test Case:
Blocked By: Blocking:
Related Tickets: #7097 #7134 #7040 Differential Rev(s):
Wiki Page:

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 5 years 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 5 years ago by igloo

Blocked By: 3658 added

comment:3 Changed 5 years ago by igloo

difficulty: Unknown
Milestone: 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 4 years ago by bos

Blocked By: 3658 removed

comment:5 Changed 4 years ago by bos

Resolution: duplicate
Status: newclosed

Dup of #7134.

Note: See TracTickets for help on using tickets.