Opened 8 months ago

Closed 8 months ago

#8236 closed bug (fixed)

Assertion failure of MarkWeak

Reported by: kazu-yamamoto Owned by:
Priority: high Milestone: 7.8.1
Component: Runtime System Version: 7.7
Keywords: Cc: akio, AndreasVoellmy, simonmar, tibbe
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime crash Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

Running a web server compiled with GHC head specifying "-debug" got the following error:

mighty-20130905: internal error: ASSERTION FAILED: file rts/sm/MarkWeak.c, line 371 

    (GHC version 7.7.20130901 for i386_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Here is Akio's guess:

I wonder if this issue could have been introduced by the commit:

https://github.com/ghc/ghc/commit/6770663f764db76dbb7138ccb3aea0527d194151

It looks like after the commit, addCFinalizerToWeak# can call into the GC
with the closure lock held. This means the info pointer points to
stg_WHITEHOLE_info, breaking the asserted invariant. I haven't done any
testing to confirm this, however.

Attachments (1)

weak-assertion.hs (1.8 KB) - added by akio 8 months ago.
test case

Download all attachments as: .zip

Change History (10)

comment:1 Changed 8 months ago by simonmar

It's probably not a real problem. But if you could find out the closure type in the event that the assertion fails that would help - either run gdb on the core dump, or change the assertion to print out the closure type.

Changed 8 months ago by akio

test case

comment:2 Changed 8 months ago by akio

I attached a file that I think reproduces this problem.

If I compile it like

ghc-stage1 weak-assertion.hs -threaded -O2

and run it, it doesn't terminate (but it should). If I add -threaded, it shows the same assertion failure as the original problem:

    (GHC version 7.7.20130906 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
Version 0, edited 8 months ago by akio (next)

comment:3 Changed 8 months ago by akio

With my test case above, the bug actually affects the bahavior, probably because evacuate() goes into an infinite loop when a closure incorrectly gets the type WHITEHOLE.

I'm preparing a patch.

comment:4 Changed 8 months ago by kazu-yamamoto

Even 6770663f764db76dbb7138ccb3aea0527d194151 is reverted, a web server (Mighty) got the same error. Probably, we have two problems, week reference and another thing.

I will try to get the type of closure.

comment:5 Changed 8 months ago by akio

OK, I created #8242 for my case.

comment:6 Changed 8 months ago by kazu-yamamoto

My previous comment was not correct. Please forget.

Now I applied Akio's patch to GHC and compiled Mighty and run it with -N3 in the real world.

comment:7 Changed 8 months ago by simonmar

So do we believe this bug is addressed by the fix in #8242? It certainly looks like it to me.

comment:8 Changed 8 months ago by kazu-yamamoto

Mighty is still running. I would like to watch Mighty for two more days to close this ticket.

comment:9 Changed 8 months ago by kazu-yamamoto

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

Happily, Mighty is still running. Great. Let's close this ticket.

Note: See TracTickets for help on using tickets.