Opened 5 years ago

Closed 5 years ago

#9001 closed bug (fixed)

unexpected runtime crash

Reported by: jwlato Owned by: simonmar
Priority: highest Milestone: 7.8.3
Component: Runtime System Version: 7.8.2
Keywords: Cc: simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by simonpj)

Apologies for the poor summary, I'm not sure how to be more descriptive. I don't see anything dodgy here.

Compiling the attached program ghc -O -dcore-lint Test.hs and running it results in a runtime crash. Various incarnations of this code have resulted in

    Test: internal error: scavenge_one: strange object 0
    Test: internal error: stg_ap_p_ret

and core dumps with no further information.

I've been able to reproduce this with ghc-7.8.2 and ghc-7.6.3.

Attachments (1)

Test.hs (2.2 KB) - added by jwlato 5 years ago.

Download all attachments as: .zip

Change History (11)

Changed 5 years ago by jwlato

Attachment: Test.hs added

comment:1 Changed 5 years ago by goldfire

I can reproduce this behavior on Mac OS 10.8.5 & GHC 7.8.2.

After a bunch of (presumably expected) output, I get

Test: internal error: scavenge_one: strange object 0
    (GHC version 7.8.2 for x86_64_apple_darwin)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Abort trap: 6

comment:2 Changed 5 years ago by rwbarton

Cc: simonmar added
Component: CompilerRuntime System
Owner: set to simonmar

I can reproduce it on Linux also. It seems to be related to stack overflow handling somehow: when I run with -k1M the program completes successfully (even with the -Dg and -DS debug options too). (Though it could still be either a bug in the runtime system or a bug in the code generation.)

comment:3 Changed 5 years ago by rwbarton

It looks like the stack overflows in a long sequence of stg_ap_* function calls and the overflow isn't detected until a point at which Sp is not only less than SpLim but even less than the start of the stack segment, whereupon bad things happen.

Isn't it bad that these stg_ap_*_fast functions push things onto the stack without checking for overflow?

comment:4 Changed 5 years ago by monoidal

I've reduced the testcase, but it got messy; compiling ghc-7.8.2 X.hs and running should give an internal error:

{-# LANGUAGE RankNTypes #-}

newtype FMList = FM {unFM :: forall m. m -> m}

main = print (delete (FM id) :: Int)

delete (FM a) = a $ delete $ FM $ \g -> a (const g) undefined
Last edited 5 years ago by monoidal (previous) (diff)

comment:5 Changed 5 years ago by simonmar

Milestone: 7.8.3
Priority: normalhighest

comment:6 Changed 5 years ago by simonmar

Yes, it looks like missing stack checks in the stg_ap_*_fast functions. I'm looking into it.

comment:7 Changed 5 years ago by simonpj

Description: modified (diff)

comment:8 Changed 5 years ago by Simon Marlow <marlowsd@…>

In fc0ed8a7309e7cc863b8155fae6b57cb23331c44/ghc:

Add missing stack checks to stg_ap_* functions (#9001)

comment:9 Changed 5 years ago by simonmar

Status: newmerge

comment:10 Changed 5 years ago by thoughtpolice

Resolution: fixed
Status: mergeclosed

Merged, thanks!

Note: See TracTickets for help on using tickets.