Opened 8 years ago

Closed 8 years ago

#696 closed bug (invalid)

segmentation fault in ./genprimopcode (x86_64)

Reported by: taral Owned by: simonmar
Priority: normal Milestone: 6.4.2
Component: Compiler (NCG) Version: 6.4.1
Keywords: Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

(ghc 6.4.1-1 from debian, compiling ghc-6.5.20060211)

SRC_HC_OPTS = -H128m -O -fasm -Rghc-timing

./primopcode segfaults.

/usr/bin/ghc -H128m -O -fasm -Rghc-timing -package parsec    -c Main.hs -o Main.o  -ohi Main.hi
/usr/bin/ghc -o genprimopcode -H128m -O -fasm -Rghc-timing -package parsec       Main.o
/usr/bin/ghc -M -optdep-f -optdep.depend  -osuf o    -H128m -O -fasm -Rghc-timing -package parsec Main.hs

Attachments (2)

null.s (6.9 KB) - added by taral 8 years ago.
"main = return ()" -fvia-C
null.fasm.s (2.8 KB) - added by taral 8 years ago.
"main = return ()" -fasm

Download all attachments as: .zip

Change History (9)

comment:1 Changed 8 years ago by simonmar

  • Milestone set to 6.4.2
  • Owner set to simonmar

comment:2 Changed 8 years ago by simonmar

I can't repeat this one. Anyone else?

Changed 8 years ago by taral

"main = return ()" -fvia-C

Changed 8 years ago by taral

"main = return ()" -fasm

comment:3 Changed 8 years ago by simonmar

taral - does the -fasm version of the null program crash for you?

comment:4 Changed 8 years ago by taral

Yup. It crashes at:

movq $GHCziTopHandler_topHandler_closure,8(%rbx)

because rbx points into code, if I remember correctly.

comment:5 Changed 8 years ago by simonmar

null.s looks like it is unregisterised, whereas null.fasm.s is registerised. This would explain the crash: if the default RTS is unregisterised, linking registerised code against it will fail.

So I guess your Debian build of GHC 6.4.1 is unregisterised. This is something you should probably look into - there's no reason to have an unregisterised build of 6.4.1 for x86_64, registerised works fine and is a lot faster (and -fasm works).

It is usual to disable the native code generator for a registerised build. I guess the Debian folks didn't do this. I'll look into providing more safety checks in GHC to make sure you get a sensible error message rather than a crash in the future.

comment:6 Changed 8 years ago by taral

I'll file a Debian bug then. Thanks!

comment:7 Changed 8 years ago by taral

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

From the 6.4.1-2 changelog (not published yet?):

  • On the list of arches we build registerised:
    • Add amd64.
Note: See TracTickets for help on using tickets.