[GHC] #13617: Segfault in Windows GHCi involving C code compiled with -O4

older
[GHC] #15638: Make Ptr argument to...

GHC

26 Apr 2017 26 Apr '17

3:16 p.m.

#13617: Segfault in Windows GHCi involving C code compiled with -O4 ----------------------------------------+------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- This is a very elusive bug that I noticed when running an `hmatrix` example under GHCi on Windows. Luckily, this example can be reduced down to a couple of `.hs` files and a single `.c` file (with no other Haskell or C dependencies). Unfortunately, I can't quite figure out a way to reproduce this bug without `cabal`, so I've put the source code at https://github.com/RyanGlScott/hmatrix-segfault. You can reproduce this bug by doing the following: {{{ $ git clone https://github.com/RyanGlScott/hmatrix-segfault $ git reset 2bfe38f964fca64dd776993c89ec59d35fb368a5 $ cd hmatrix-segfault/ $ cabal install $ runghc exe/Main.hs Access violation in generated code when reading ffffffffffffffff }}} Running `Main.hs` in GHCi crashes, whereas compiling it works: {{{ $ ghc exe/Main.hs $ ./exe/Main.exe [1,1,1,1,1,1,1,1,1,1,1,1] }}} I've reproduced this with GHC 7.10.3, 8.0.2, and 8.2.1-rc1. There are a couple of things that appear to be necessary to trigger the segfault: 1. You need to have `-O4` under `cc-options` in `hmatrix-segfault.cabal`. 2. You need to define the [https://github.com/RyanGlScott/hmatrix- segfault/blob/2bfe38f964fca64dd776993c89ec59d35fb368a5/src/Internal/Vectorized.hs#L38 FunCodeS] datatype. Removing either of these things causes the program to work again under GHCi. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13617 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

Show replies by date

GHC

3 Jun 3 Jun

10:06 p.m.

#13617: Segfault in Windows GHCi involving C code compiled with -O4 --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by RyanGlScott): As Phyx- pointed out to me, `-O4` is just an alias for `-O3` in `gcc` and `clang`, so the issue is really with `-O3`. I've confirmed that setting `gcc-options: -O3` also triggers this segfault, but not with `gcc-options: -O2`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13617#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

GHC

9 Jul 9 Jul

7:33 a.m.

New subject: [GHC] #13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation (was: Segfault in Windows GHCi involving C code compiled with -O4)

#13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * related: => #7134 Comment: So I've finally had some time to track this one down. The difference between the `-O2` and the `-O3` code is that the `-O3` code is vectorized and the constants are moved to `.rdata`. To get to the constants a `R_X86_64_PC32` relocation is used. {{{ ac: 48 c1 e0 02 shl $0x2,%rax b0: 31 db xor %ebx,%ebx b2: 66 0f 6f 15 00 00 00 movdqa 0x0(%rip),%xmm2 # ba b9: 00 b6: R_X86_64_PC32 .rdata ba: 48 8d 2c 02 lea (%rdx,%rax,1),%rbp be: 41 c1 ea 02 shr $0x2,%r10d }}} At runtime the program segfaults at `0xb2` when attempting to read from `.rdata`. {{{ │0xced01d2 shl $0x2,%rax │ │0xced01d6 xor %ebx,%ebx │

...

│0xced01d8 movdqa 0xd8(%rip),%xmm2 # 0xced02b8 │ │0xced01e0 lea (%rdx,%rax,1),%rbp │ │0xced01e4 shr $0x2,%r10d }}}

The calculated address for `.rdata` is correct, `0xced02b8`: {{{ (gdb) x/10i 0xced02b8 0xced02b8: add %eax,(%rax) 0xced02ba: add %al,(%rax) 0xced02bc: add %eax,(%rax) 0xced02be: add %al,(%rax) 0xced02c0: add %eax,(%rax) 0xced02c2: add %al,(%rax) 0xced02c4: add %eax,(%rax) 0xced02c6: add %al,(%rax) 0xced02c8: rex.RXB 0xced02c9: rex.XB }}} and the object file has {{{ Disassembly of section .rdata: 0000000000000000 <.rdata>: 0: 01 00 add %eax,(%rax) 2: 00 00 add %al,(%rax) 4: 01 00 add %eax,(%rax) 6: 00 00 add %al,(%rax) 8: 01 00 add %eax,(%rax) a: 00 00 add %al,(%rax) c: 01 00 add %eax,(%rax) ... }}} However the code is referencing this address. So I suspect it's expecting a trampoline here. So perhaps `R_X86_64_PC32` should be allocated using a jump island. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13617#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

GHC

7:52 a.m.

New subject: [GHC] #13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation

#13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by Phyx-): It seems the code for `R_X86_64_PC32` does already make a trampoline, but only when the address is more than `32-bits` away: {{{ case 4: /* R_X86_64_PC32 (ELF constant 2) - IMAGE_REL_AMD64_REL32 (PE constant 4) */ { intptr_t v; v = ((intptr_t)S) + ((intptr_t)(int32_t)A) - ((intptr_t)pP) - 4; if ((v >> 32) && ((-v) >> 32)) { /* Make the trampoline then */ copyName ( getSymShortName (info, sym), strtab, symbol, 1000-1 ); S = makeSymbolExtra_PEi386(oc, symIndex, S, (char *)symbol); /* And retry */ v = ((intptr_t)S) + ((intptr_t)(int32_t)A) - ((intptr_t)pP) - 4; if ((v >> 32) && ((-v) >> 32)) { barf("IMAGE_REL_AMD64_REL32: High bits are set in %zx for %s", v, (char *)symbol); } } *(uint32_t *)pP = (uint32_t)v; break; } }}} Which explains why it doesn't always segfault.. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13617#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

GHC

3 p.m.

New subject: [GHC] #13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi (was: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation)

#13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by Phyx-): My initial analysis was wrong, the code isn't expecting a trampoline, it's data not code. It's simply trying to load the loop iteration increment into the SSE registers. {{{ (gdb) x/10x 0xced02b8 0xced02b8: 0x00000001 0x00000001 0x00000001 0x00000001 0xced02c8: 0x3a434347 0x65522820 0x202c3276 0x6c697542 0xced02d8: 0x79622074 0x59534d20 }}} The loop seems to have undergone 4-way vectorization. I'm not certain why this is failing.. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13617#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

GHC

6:40 p.m.

New subject: [GHC] #13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi

#13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by olsner): I think the issue is alignment - `movdqa` requires 16-byte alignment and the data here seems to start at `0x...8` which is only 8-byte aligned. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13617#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

GHC

10 Jul 10 Jul

12:26 a.m.

New subject: [GHC] #13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi

#13617: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi --------------------------------+---------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #7134 | Differential Rev(s): Wiki Page: | --------------------------------+---------------------------------------- Comment (by Phyx-): Ack, how did I miss the alignment note on the manual.. You're right, and the section is supposed to be 16-byte aligned {{{ 6 .rdata 00000010 0000000000000000 0000000000000000 000002ec 2**4 CONTENTS, ALLOC, LOAD, READONLY, DATA }}} Simple enough fix. Thanks @olsner, completely read over that a few times.. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13617#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

GHC

12:26 a.m.

New subject: [GHC] #13617: GHCi linker does not honor alignment of sections. (was: Segfault when using SSE and R_X86_64_PC32 relocations to .rdata on Windows in GHCi)