[GHC] #14915: T2783 fails with the threaded1 way

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[GHC] #14915: T2783 fails with the threaded1 way

GHC - devs mailing list
#14915: T2783 fails with the threaded1 way
           Reporter:  alpmestan       |             Owner:  (none)
               Type:  bug             |            Status:  new
           Priority:  normal          |         Milestone:
          Component:  Runtime System  |           Version:  8.5
           Keywords:                  |  Operating System:  Linux
       Architecture:  x86_64 (amd64)  |   Type of failure:  Runtime crash
          Test Case:  T2783           |        Blocked By:
           Blocking:                  |   Related Tickets:
Differential Rev(s):                  |         Wiki Page:
 When running `./validate --slow` the other day, I saw the XXX test failing
 with the `threaded1` way. Instead of detecting the loop and aborting with
 an informative message, we get an assertion failure in the
 `rts/ThreadPaused.c:threadPaused` function.

 The program:

 main = print $ do x <- [ 0 .. 5 ] ; let { y = 5 - y } ; return y

 The output:

 =====> T2783(threaded1) 1 of 1 [0, 0, 0]
 cd "./rts/T2783.run" &&  "/home/alp/ghc/inplace/test   spaces/ghc-stage2"
 -o T2783 T2783.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts
 -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-
 color=never -fno-diagnostics-show-caret -dno-debug-output  -threaded
 cd "./rts/T2783.run" && ./T2783
 Wrong exit code for T2783(threaded1)(expected 1 , actual 134 )
 Stderr ( T2783 ):
 T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314

     (GHC version 8.5.20180306 for x86_64_unknown_linux)
     Please report this as a GHC bug:
 Aborted (core dumped)
 *** unexpected failure for T2783(threaded1)

 The code for the corresponding assertion:

 // We should never have made it here in the event of blackholes that
 // we already own; they should have been marked when we blackholed
 // them and consequently we should have stopped our stack walk
 // above.
 ASSERT(!((bh_info == &stg_BLACKHOLE_info)
          && (((StgInd*)bh)->indirectee == (StgClosure*)tso)));

 This seems to be an actual problem, hence this ticket.

Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14915>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

ghc-tickets mailing list
[hidden email]