Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#6146 closed bug (fixed)

Segmentation fault with eager blackholing

Reported by: emcdowell Owned by: simonmar
Priority: high Milestone: 7.4.3
Component: Runtime System Version: 7.4.1
Keywords: eager blackholing Cc:
Operating System: Windows Architecture: x86
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


When very simple programs are compiled using the -feager-blackholing and -threaded flags in GHC 7.4.1 on Windows 7 and XP a segmentation fault frequently occurs during execution. This happens in programs that read a line from the keyboard and print a response. The problem occurs running the executable file directly, through ghci, and through runghc.

The problem is resolved by compiling without the -feager-blackholing flag.

Attachments (2)

Main.hs (260 bytes) - added by emcdowell 3 years ago.
Main.2.hs (1.5 KB) - added by emcdowell 3 years ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 3 years ago by emcdowell

In trying to reproduce this I got different erroneous behavior. When entering small input values the code behaves as expected. When entering larger values, part of the output is truncated. The following problem is easily reproduced on Windows XP.

H:\user\haskell\Test>type Main.hs
module Main (main) where

main :: IO ()
main = do
    putStrLn "First number?  "
    num1 <- readLn :: IO Int
    putStrLn "Second number? "
    num2 <- readLn :: IO Int
    let total = num1 + num2
    putStrLn $ "The sum is " ++ (show total) ++ "."

H:\user\haskell\Test>ghc -feager-blackholing -threaded --make Main.hs
[1 of 1] Compiling Main             ( Main.hs, Main.o )
Linking Main.exe ...

H:\user\haskell\Test>main +RTS -N
First number?
Second number?
The sum is 5.

H:\user\haskell\Test>main +RTS -N
First number?
Second number?

Changed 3 years ago by emcdowell


Changed 3 years ago by emcdowell


comment:2 Changed 3 years ago by emcdowell

I have attached the original program where I encountered the problem. You should be able to reproduce this.

H:\user\haskell\Pi>ghc -threaded -feager-blackholing --make Pi.hs
[1 of 1] Compiling Main             ( Pi.hs, Pi.o )
Linking Pi.exe ...

H:\user\haskell\Pi>Pi.exe +RTS -N
Terms?  1000
Tasks?  2

H:\user\haskell\Pi>Pi.exe +RTS -N
Terms?  10000000
Segmentation fault/access violation in generated code

H:\user\haskell\Pi>ghc -threaded --make Pi.hs

H:\user\haskell\Pi>erase Pi.o

H:\user\haskell\Pi>erase Pi.hi

H:\user\haskell\Pi>erase Pi.exe

H:\user\haskell\Pi>ghc -threaded --make Pi.hs
[1 of 1] Compiling Main             ( Pi.hs, Pi.o )
Linking Pi.exe ...

H:\user\haskell\Pi>Pi.exe +RTS -N
Terms?  10000000
Tasks?  2


comment:3 Changed 3 years ago by simonmar

  • Component changed from Compiler to Runtime System
  • difficulty set to Unknown
  • Milestone set to 7.4.2
  • Owner set to simonmar
  • Priority changed from normal to high

comment:4 Changed 3 years ago by marlowsd@…

commit 21a53a1cd5a9784aca7b78cc972f917e71938124

Author: Simon Marlow <[email protected]>
Date:   Thu Jun 7 15:45:32 2012 +0100

    Fix for earger blackholing of thunks with no free variables (#6146)
    A thunk with no free variables was not getting blackholed when
    -feager-blackholing was on, but we were nevertheless pushing the
    stg_bh_upd_frame version of the update frame that expects to see a
    black hole.
    I fixed this twice for good measure:
     - we now call blackHoleOnEntry when pushing the update frame to check
       whether the closure was actually blackholed, and so that we use the
       same predicate in both places
     - we now black hole thunks even if they have no free variables.
       These only occur when optimisation is off, but presumably if you say
       -feager-blackholing then that's what you want to happen.

 compiler/codeGen/CgClosure.lhs    |    7 ++++---
 compiler/codeGen/ClosureInfo.lhs  |    2 +-
 compiler/codeGen/StgCmmBind.hs    |   17 ++++++++++-------
 compiler/codeGen/StgCmmClosure.hs |    2 +-
 4 files changed, 16 insertions(+), 12 deletions(-)

comment:5 Changed 3 years ago by simonmar

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

Thanks, nice bug.

comment:6 Changed 3 years ago by simonmar

  • Status changed from closed to merge

duh, keep forgetting to set these to merge, sorry for the spam.

comment:7 Changed 3 years ago by pcapriotti

  • Status changed from merge to closed

comment:8 Changed 3 years ago by simonmar

  • Milestone changed from 7.4.2 to 7.4.3
Note: See TracTickets for help on using tickets.