[GHC] #15508: concprog001 fails with various errors when compiled with -prof

newer
[GHC] #14037: Fix fusion for GHC's...

older
[GHC] #8657: -fregs-graph still...

GHC

12 Aug 2018 12 Aug '18

7:15 a.m.

#15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5051 | Wiki Page: -------------------------------------+------------------------------------- I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. Reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet. It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It seems to work fine when not compiled for profiling so marking this bug as a profiler bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

Show replies by date

GHC

12 Aug 12 Aug

7:22 a.m.

...

I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now.

Reproduce with GHC HEAD:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210

(GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}}

I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet.

It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}}

Yet another way:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}}

It seems to work fine when not compiled for profiling so marking this bug as a profiler bug.

New description: I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. The reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_one: strange object 624722688 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations. Note that for the examples below you'll need debug + profiling or debug + profiling + threaded runtimes, which are not built by default. To build those apply this patch: {{{ diff --git a/mk/config.mk.in b/mk/config.mk.in index 11050120d4..f083abad22 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -297,6 +297,7 @@ GhcRTSWays=l # Usually want the debug version GhcRTSWays += debug +GhcRTSWays += thr_debug_p debug_p # We always have the threaded versions, but note that SMP support may be disabled # (see GhcWithSMP). diff --git a/rts/ghc.mk b/rts/ghc.mk index 532c9aa175..ff3f18f30c 100644 --- a/rts/ghc.mk +++ b/rts/ghc.mk @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes WARNING_OPTS += -Wmissing-prototypes WARNING_OPTS += -Wmissing-declarations WARNING_OPTS += -Winline -WARNING_OPTS += -Waggregate-return WARNING_OPTS += -Wpointer-arith WARNING_OPTS += -Wmissing-noreturn WARNING_OPTS += -Wnested-externs }}} Examples: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} (I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet.) Another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It seems to work fine when not compiled for profiling so marking this bug as a profiler bug. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

21 Aug 21 Aug

4:09 p.m.

GHC

10:56 p.m.

GHC

11:30 p.m.

GHC

22 Aug 22 Aug

5:47 a.m.

GHC

5:54 a.m.

GHC

6:44 a.m.

...

I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now.

The reproduce with GHC HEAD:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ...

prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_one: strange object 624722688 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}}

It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations. Note that for the examples below you'll need debug + profiling or debug + profiling + threaded runtimes, which are not built by default. To build those apply this patch:

{{{ diff --git a/mk/config.mk.in b/mk/config.mk.in index 11050120d4..f083abad22 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -297,6 +297,7 @@ GhcRTSWays=l

# Usually want the debug version GhcRTSWays += debug +GhcRTSWays += thr_debug_p debug_p

# We always have the threaded versions, but note that SMP support may be disabled # (see GhcWithSMP). diff --git a/rts/ghc.mk b/rts/ghc.mk index 532c9aa175..ff3f18f30c 100644 --- a/rts/ghc.mk +++ b/rts/ghc.mk @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes WARNING_OPTS += -Wmissing-prototypes WARNING_OPTS += -Wmissing-declarations WARNING_OPTS += -Winline -WARNING_OPTS += -Waggregate-return WARNING_OPTS += -Wpointer-arith WARNING_OPTS += -Wmissing-noreturn WARNING_OPTS += -Wnested-externs }}}

Examples:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ...

prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210

(GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}}

(I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet.)

Another way:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ...

prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}}

Yet another way:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ...

prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}}

It seems to work fine when not compiled for profiling so marking this bug as a profiler bug.

New description: I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. The reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_one: strange object 624722688 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_stack: weird activation record found on stack: 0 (GHC version 8.7.20180821 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations. Note that for the examples below you'll need debug + profiling or debug + profiling + threaded runtimes, which are not built by default. To build those apply this patch: {{{ diff --git a/mk/config.mk.in b/mk/config.mk.in index 11050120d4..f083abad22 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -297,6 +297,7 @@ GhcRTSWays=l # Usually want the debug version GhcRTSWays += debug +GhcRTSWays += thr_debug_p debug_p # We always have the threaded versions, but note that SMP support may be disabled # (see GhcWithSMP). diff --git a/rts/ghc.mk b/rts/ghc.mk index 532c9aa175..ff3f18f30c 100644 --- a/rts/ghc.mk +++ b/rts/ghc.mk @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes WARNING_OPTS += -Wmissing-prototypes WARNING_OPTS += -Wmissing-declarations WARNING_OPTS += -Winline -WARNING_OPTS += -Waggregate-return WARNING_OPTS += -Wpointer-arith WARNING_OPTS += -Wmissing-noreturn WARNING_OPTS += -Wnested-externs }}} Examples: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} (I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet.) Another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It seems to work fine when not compiled for profiling so marking this bug as a profiler bug. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

9:18 a.m.

...

...
...
print cap->r.rCCCS $13 = (struct CostCentreStack_ *) 0x4200213000

...

...
...
call printClosure(cap->r.rCCCS) integer-gmp:GHC.Integer.Type.S#((nil)#) }}}

Then when this capability does allocation `accountAllocation` overwrites a info table pointer in this line {{{ CCS_ALLOC(cap->r.rCCCS,n); // Storage.c:802 }}} CCS_ALLOC defined as: {{{ #define CCS_ALLOC(ccs, size) (ccs)->mem_alloc += ((size)-sizeofW(StgProfHeader)) }}} mem_alloc is at this address: {{{

...

...
...
print &cap->r.rCCCS->mem_alloc $15 = (StgWord64 *) 0x4200213048 }}}

Which is also the info ptr of another closure: {{{

...

...
...
print &((StgClosure*)0x4200213048)->header.info $20 = (const StgInfoTable **) 0x4200213048 }}}

Originally this closure is; {{{

...

...
...
call printClosure(0x4200213048) BLACKHOLE(0x42000dfa40) }}}

So this assignment causes a memory corruption. Note that I'm using `+RTS -DS` during all this so any heap location that is not filled with 0 are actually in use. (collected space is filled with 0s with `-DS`) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

10:35 a.m.

GHC

23 Aug 23 Aug

7:43 a.m.

...

I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now.

The reproduce with GHC HEAD:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ...

prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_one: strange object 624722688 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2

prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_stack: weird activation record found on stack: 0 (GHC version 8.7.20180821 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2

prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}}

It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations. Note that for the examples below you'll need debug + profiling or debug + profiling + threaded runtimes, which are not built by default. To build those apply this patch:

{{{ diff --git a/mk/config.mk.in b/mk/config.mk.in index 11050120d4..f083abad22 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -297,6 +297,7 @@ GhcRTSWays=l

# Usually want the debug version GhcRTSWays += debug +GhcRTSWays += thr_debug_p debug_p

# We always have the threaded versions, but note that SMP support may be disabled # (see GhcWithSMP). diff --git a/rts/ghc.mk b/rts/ghc.mk index 532c9aa175..ff3f18f30c 100644 --- a/rts/ghc.mk +++ b/rts/ghc.mk @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes WARNING_OPTS += -Wmissing-prototypes WARNING_OPTS += -Wmissing-declarations WARNING_OPTS += -Winline -WARNING_OPTS += -Waggregate-return WARNING_OPTS += -Wpointer-arith WARNING_OPTS += -Wmissing-noreturn WARNING_OPTS += -Wnested-externs }}}

Examples:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ...

prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210

(GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}}

(I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet.)

Another way:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ...

prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}}

Yet another way:

{{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ...

prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}}

It seems to work fine when not compiled for profiling so marking this bug as a profiler bug.

New description: I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. The reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_one: strange object 624722688 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_stack: weird activation record found on stack: 0 (GHC version 8.7.20180821 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations. Note that for the examples below you'll need debug + profiling or debug + profiling + threaded runtimes, which are not built by default. To build those apply this patch: {{{ diff --git a/mk/config.mk.in b/mk/config.mk.in index 11050120d4..f083abad22 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -297,6 +297,7 @@ GhcRTSWays=l # Usually want the debug version GhcRTSWays += debug +GhcRTSWays += thr_debug_p debug_p # We always have the threaded versions, but note that SMP support may be disabled # (see GhcWithSMP). diff --git a/rts/ghc.mk b/rts/ghc.mk index 532c9aa175..ff3f18f30c 100644 --- a/rts/ghc.mk +++ b/rts/ghc.mk @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes WARNING_OPTS += -Wmissing-prototypes WARNING_OPTS += -Wmissing-declarations WARNING_OPTS += -Winline -WARNING_OPTS += -Waggregate-return WARNING_OPTS += -Wpointer-arith WARNING_OPTS += -Wmissing-noreturn WARNING_OPTS += -Wnested-externs }}} Examples: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} (I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet.) Another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} ~~It seems to work fine when not compiled for profiling so marking this bug as a profiler bug.~~ This program fails sanity checks with non-threaded and non-profiling runtime too: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -fforce-recomp -debug -rtsopts [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: checkClosure: stack frame (GHC version 8.7.20180821 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} -- Comment: While messing around with different flags I realized that we don't need profiling or threaded flags, it fails some sanity checks in non-threaded non-profiled runtime. Updated the description and reverted the component from profiler to compiler (not sure if this is a codegen or RTS issue). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

27 Aug 27 Aug

6:54 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors (was: concprog001 fails with various errors when compiled with -prof)

#15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

10:03 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

#15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #15571 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

28 Aug 28 Aug

7:41 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

17 Sep 17 Sep

7:17 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

18 Sep 18 Sep

5:07 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

21 Sep 21 Sep

7:24 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

...

...
...
bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007f7bf5709801 in __GI_abort () at abort.c:79 #2 0x00000000007313b5 in rtsFatalInternalErrorFn (s=0x79fd90 "ASSERTION FAILED: file %s, line %u\n", ap=0x7ffe92feb8b8) at rts/RtsMessages.c:186 #3 0x0000000000730fd9 in barf (s=0x79fd90 "ASSERTION FAILED: file %s, line %u\n") at rts/RtsMessages.c:48 #4 0x000000000073103e in _assertFail (filename=0x7a55f0 "rts/sm/Sanity.c", linenum=296) at rts/RtsMessages.c:63 #5 0x0000000000751be3 in checkClosure (p=0x42008e45e0) at rts/sm/Sanity.c:295 #6 0x00000000007521b0 in checkHeapChain (bd=0x4200803900) at rts/sm/Sanity.c:450 #7 0x0000000000752bf1 in checkGeneration (gen=0x10ec408, after_major_gc=false) at rts/sm/Sanity.c:745 #8 0x0000000000752cc1 in checkFullHeap (after_major_gc=false) at rts/sm/Sanity.c:764 #9 0x0000000000752d3b in checkSanity (after_gc=false, major_gc=false) at rts/sm/Sanity.c:773 #10 0x000000000074e99b in GarbageCollect (collect_gen=0, do_heap_census=false, gc_type=0, cap=0x90e1c0 <MainCapability>, idle_cap=0x0) at rts/sm/GC.c:320 #11 0x0000000000734141 in scheduleDoGC (pcap=0x7ffe92febcb0, task=0x10fdd50, force_major=false) at rts/Schedule.c:1800 #12 0x0000000000733619 in schedule (initialCapability=0x90e1c0 <MainCapability>, task=0x10fdd50) at rts/Schedule.c:546 #13 0x0000000000734b13 in scheduleWaitThread (tso=0x4200105388, ret=0x0, pcap=0x7ffe92febdb0) at rts/Schedule.c:2537 #14 0x0000000000743205 in rts_evalLazyIO (cap=0x7ffe92febdb0, p=0x7d5710, ret=0x0) at rts/RtsAPI.c:530 #15 0x000000000074394c in hs_main (argc=1, argv=0x7ffe92febfa8, main_closure=0x7d5710, rts_config=...) at rts/RtsMain.c:72 #16 0x000000000042fd6e in main () }}}

The assertion that fails: {{{ ASSERT(bq->queue == (MessageBlackHole*)END_TSO_QUEUE || bq->queue->header.info == &stg_MSG_BLACKHOLE_info); }}} bq->queue is actually an IND: {{{

...

...
...
print bq->queue $1 = (struct MessageBlackHole_ *) 0x42001df098 call printClosure(bq->queue) IND(0x42001de350) }}}

There's a note about this in Evac.c: {{{ // Note [BLACKHOLE pointing to IND] // // BLOCKING_QUEUE can be overwritten by IND (see // wakeBlockingQueue()). However, when this happens we must // be updating the BLACKHOLE, so the BLACKHOLE's indirectee // should now point to the value. // // The mutator might observe an inconsistent state, because // the writes are happening in another thread, so it's // possible for the mutator to follow an indirectee and find // an IND. But this should never happen in the GC, because // the mutators are all stopped and the writes have // completed. }}} It seems like this currently does not hold. We're in GC and observe that a BLOCKING_QUEUE is actually an IND. Adding watchpoint to see when it became an IND: {{{

...

...
...
watch ((StgBlockingQueue *) 0x42008e45e0)->queue->header.info Hardware watchpoint 1: ((StgBlockingQueue *) 0x42008e45e0)->queue->header.info reverse-continue bt #0 0x00000000007406a0 in SET_INFO (c=0x42001df098, info=0x763e08 <stg_IND_info>) at includes/rts/storage/ClosureMacros.h:49 #1 0x0000000000740dfe in throwToMsg (cap=0x90e1c0 <MainCapability>, msg=0x42000cc180) at rts/RaiseAsync.c:412 #2 0x0000000000740905 in throwTo (cap=0x90e1c0 <MainCapability>, source=0x420040e438, target=0x42008bcc40, exception=0x7df158) at rts/RaiseAsync.c:213 #3 0x00000000007613c2 in stg_killThreadzh () #4 0x0000000000000000 in ?? () }}}

I'm not sure when this object is supposed to become a BLACKHOLE (or END_TSO_QUEUE) again. Simon, any ideas? I'm also confused why a note about blackholes talk about BLOCKING_QUEUE... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

22 Sep 22 Sep

8:33 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

24 Sep 24 Sep

7:18 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

#15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165 -------------------------------------+------------------------------------- Comment (by osa1): This is easy to fix, but I'm trying to understand the code: {{{ // Revoke the message by replacing it with IND. We're not // locking anything here, so we might still get a TRY_WAKEUP // message from the owner of the blackhole some time in the // future, but that doesn't matter. ASSERT(target->block_info.bh->header.info == &stg_MSG_BLACKHOLE_info); OVERWRITE_INFO(target->block_info.bh, &stg_IND_info); raiseAsync(cap, target, msg->exception, false, NULL); return THROWTO_SUCCESS; }}} (in throwToMsg()) Why we can make a MessageBlackHole an IND without setting the indirectee? Is this used to remove (by skipping) a MessageBlackHole from the queue? (because actually removing would be impossible as we don't have a `prev` field in `MessageBlackHole`?) I'm quite confused about how these two types are used: {{{ typedef struct StgBlockingQueue_ { StgHeader header; struct StgBlockingQueue_ *link; // here so it looks like an IND StgClosure *bh; // the BLACKHOLE StgTSO *owner; struct MessageBlackHole_ *queue; } StgBlockingQueue; typedef struct MessageBlackHole_ { StgHeader header; struct MessageBlackHole_ *link; StgTSO *tso; StgClosure *bh; } MessageBlackHole; }}} As far as I understand, a BLACKHOLE can become a BLOCKING_QUEUE (in `messageBlackHole()`), and `queue` of a BLOCKING_QUEUE is for threads that are blocked on this BLACKHOLE. But then - Why do we have a `bh` field in `messageBlackHole`? We could pass the `bh` as a parameter to `messageBlackHole()` and `bh` would the blackhole that we just looked at to find the `MessageBlackHole`. - Why do we need a list of `BLOCKING_QUEUE`s? Is this only to be able to implement `checkBlockingQueues()`? The comments around `checkBlockingQueues()` say {{{ // If we update a closure that we know we BLACKHOLE'd, and the closure // no longer points to the current TSO as its owner, then there may be // an orphaned BLOCKING_QUEUE closure with blocked threads attached to // it. We therefore traverse the BLOCKING_QUEUEs attached to the // current TSO to see if any can now be woken up. }}} but I don't understand how can owner of a BLACKHOLE not point to our capability if we BLACKHOLEd it. Could you say a few workds about this? I'll submit a patch but I don't know what to say in the commit message as I don't understand this code ... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

10:44 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

...

Why we can make a MessageBlackHole an IND without setting the indirectee? Is this used to remove (by skipping) a MessageBlackHole from the queue? (because actually removing would be impossible as we don't have a prev field in MessageBlackHole?)

Yes, exactly.

...

As far as I understand, a BLACKHOLE can become a BLOCKING_QUEUE (in messageBlackHole()), and queue of a BLOCKING_QUEUE is for threads that are blocked on this BLACKHOLE.

Just to be clear, A BLACKHOLE doesn't "become" a BLOCKING_QUEUE, the BLACKHOLE's indirectee field points to the BLOCKING_QUEUE.

...

Why do we have a bh field in messageBlackHole? We could pass the bh as a parameter to messageBlackHole() and bh would the blackhole that we just looked at to find the MessageBlackHole.

A MessageBlackHole is sent to another capability, which needs to know which BLACKHOL to add it to.

...

Why do we need a list of BLOCKING_QUEUEs? Is this only to be able to implement checkBlockingQueues()? The comments around checkBlockingQueues() say

See this comment in `messageBlackHole()`: {{{ // All BLOCKING_QUEUES are linked in a list on owner->bq, so // that we can search through them in the event that there is // a collision to update a BLACKHOLE and a BLOCKING_QUEUE // becomes orphaned (see updateThunk()). }}}

...

but I don't understand how can owner of a BLACKHOLE not point to our capability if we BLACKHOLEd it.

A BLACKHOLE can be updated by another thread at any time. The fact that it is a BLACKHOLE is not an exclusive ownership. We use compare-and-swap to install the BLACKHOLE in `threadPaused()`, but another thread might already be evaluating the thunk and will update it with the value later, and we don't use a compare-and-swap when updating because that would be too expensive. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

12:57 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

1:48 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

5 Oct 5 Oct

11:36 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

6 Oct 6 Oct

6:25 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

29 Nov 29 Nov

2:01 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

2:23 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

4 Jan 4 Jan

11:59 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

...

...
...
print *(StgClosure*)0x4207528048 $34 = { header = { info = 0x9f2200 <ghczmprim_GHCziTypes_ZC_con_info>, prof = { ccs = 0xb44390, hp = { rs = 0x0, ldvw = 0 } } }, payload = 0x4207528060 } call printClosure((StgClosure*)0x4207528048) ghc-prim:GHC.Types.:(0x42075280b9, 0x4207528092) }}}

After that line: {{{

...

...
...
print *(StgClosure*)0x4207528048 $40 = { header = { info = 0x9f2203 <ghczmprim_GHCziTypes_ZC_con_info+3>, prof = { ccs = 0xb44390, hp = { rs = 0x0, ldvw = 0 } } }, payload = 0x4207528060 } }}}

This is not a valid closure anymore. I don't know what that code is supposed to increment. I'll try to generate Cmm for `GHC.Conc.Sync.childHandler` and see. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

12:08 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

12:26 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

...

...
...
bt #0 0x0000000000a376f8 in stg_returnToStackTop () #1 0x0000000000000000 in ?? ()

...

...
...
call printClosure(0x4207528000) ghc-prim:GHC.Types.:(0x4207528071, 0x420752804a) }}}

-- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

12:58 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

...

...
...
bt #0 0x0000000000a37819 in stg_returnToSched () #1 0x0000000000000000 in ?? ()

...

...
...
print *(CostCentreStack *)0xb44390 $60 = { ccsID = 241, cc = 0xb44350, prevStack = 0xd2df00 <CCS_MAIN>, indexTable = 0x0, root = 0xb44390, depth = 1, scc_count = 0, selected = 1, time_ticks = 0, mem_alloc = 59522365, inherited_alloc = 0, inherited_ticks = 0 } }}}

(Note that this is reverse executions so "old" is actually new) Interestingly at this point 0x4207528000 actually looks like a valid cost centre stack: {{{

...

...
...
print *(CostCentreStack *)0x4207528000 $62 = { ccsID = 283607809913, cc = 0xb44390, prevStack = 0x5, indexTable = 0x4207528071, root = 0x420752804a, depth = 283607809953, scc_count = 11813776, selected = 4, time_ticks = 0, mem_alloc = 283607809985, inherited_alloc = 11813776, inherited_ticks = 5 }

...

...
...
print *((CostCentreStack *)0x4207528000)->cc $64 = { ccID = 241, label = 0xb44350 "\a", module = 0xd2df00 <CCS_MAIN> "|", srcloc = 0x0, mem_alloc = 11813776, time_ticks = 1, is_caf = 0, link = 0x1 } }}}

So currently we don't have a problem. If I continue: {{{ Thread 2 hit Hardware watchpoint 8: ((StgTSO *) 0x420019d7e0)->prof.cccs Old value = (CostCentreStack *) 0xb44390 New value = (CostCentreStack *) 0x4207528000 0x0000000000a3d1c2 in stg_AP_STACK_info ()

...

...
...
bt #0 0x0000000000a3d1c2 in stg_AP_STACK_info () #1 0x0000000000000000 in ?? ()

...

...
...
print *(StgClosure*)0x4207528000 $69 = { header = { info = 0x9f2200 <ghczmprim_GHCziTypes_ZC_con_info>, prof = { ccs = 0xb44390, hp = { rs = 0x0, ldvw = 0 } } }, payload = 0x4207528018 } }}}

This is the second time we update the `TSO->prof` with the problematic value, and NOW things look bad. I don't understand how we can use the same location for a cost centre stack and a heap closure. As far as I know cost centre stacks are allocated in an arena, and are never freed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

6 Jan 6 Jan

9:06 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

...

...
...
print ((StgClosure *) 0x4200345e70)->header.prof.ccs $30 = (CostCentreStack *) 0xb44390 print *((StgClosure *) 0x4200345e70)->header.prof.ccs $31 = { ccsID = 241, cc = 0xb44350, prevStack = 0xd2df00 <CCS_MAIN>, indexTable = 0x0, root = 0xb44390, depth = 1, scc_count = 0, selected = 1, time_ticks = 0, mem_alloc = 59522362, inherited_alloc = 0, inherited_ticks = 0 } }}}

The new value is `0x4207528000`, a location in the heap. The new location is coming from another closure so I should debug more and see how the value ended up in that closure, but I noticed a `TODO` comment around the code that makes this assignment: {{{ -- RaiseAsync.c:873 SET_HDR(ap,&stg_AP_STACK_info, ((StgClosure *)frame)->header.prof.ccs /* ToDo */); }}} I wonder if that `ToDo` has anything to do with this. @simonmar, any ideas? The commit that added that `ToDo`: b1953bbb1ed3cb16497e5447db7487f0c2d9e41a. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

9 Jan 9 Jan

8:31 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

10 Jan 10 Jan

8:13 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

8:59 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

10:49 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

12 Jan 12 Jan

12:35 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

12:44 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

1:12 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

2:23 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

13 Jan 13 Jan

5:40 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

15 Jan 15 Jan

9:40 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

...

...
...
bt #0 0x0000000000a0ed5d in StgRunIsImplementedInAssembler () at rts/StgCRun.c:370 #1 0x0000000000a0226a in schedule (initialCapability=0xd2c600 <MainCapability>, task=0x242dd70) at rts/Schedule.c:452 #2 0x0000000000a03b7b in scheduleWaitThread (tso=0x4200105370, ret=0x0, pcap=0x7ffdbfd88f10) at rts/Schedule.c:2547 #3 0x0000000000a15e4b in rts_evalLazyIO (cap=0x7ffdbfd88f10, p=0xb3bb98, ret=0x0) at rts/RtsAPI.c:530 #4 0x0000000000a175d3 in hs_main (argc=1, argv=0x7ffdbfd89108, main_closure=0xb3bb98, rts_config=...) at rts/RtsMain.c:72 #5 0x0000000000463e78 in main () }}}

If I step a few instructions I see these instructions being executed {{{ 0x0000000000a35d60 stg_ap_0_fast+336 mov 0x8(%rbp),%rax 0x0000000000a35d64 stg_ap_0_fast+340 mov 0x10(%rbp),%rbx 0x0000000000a35d68 stg_ap_0_fast+344 mov 0x18(%rbp),%rcx 0x0000000000a35d6c stg_ap_0_fast+348 add $0x20,%rbp 0x0000000000a35d70 stg_ap_0_fast+352 mov %rcx,%rdx }}} This is in `stg_ap_0_fast` and `%rbx` is supposed to be a FUN for a PAP, but it's actually collected by the GC: {{{

...

...
...
print (StgClosure*)$rbx $27 = (StgClosure *) 0x42000b2868 print *(StgClosure*)$rbx $28 = { header = { info = 0xaaaaaaaaaaaaaaaa, prof = { ccs = 0xaaaaaaaaaaaaaaaa, hp = { rs = 0xaaaaaaaaaaaaaaaa, ldvw = 12297829382473034410 } } }, payload = 0x42000b2880 } }}}

Interestingly only some part of it is collected (the first 3 words). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

GHC

16 Jan 16 Jan

5:52 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

17 Jan 17 Jan

5:47 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

6:29 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

18 Jan 18 Jan

7:52 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

9 Feb 9 Feb

3:52 p.m.

New subject: [GHC] #15508: concprog001 fails with various errors

GHC

10 Feb 10 Feb

4:52 a.m.

New subject: [GHC] #15508: concprog001 fails with various errors

#15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.4 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103, MR:146 -------------------------------------+------------------------------------- Changes (by osa1): * status: closed => new * owner: osa1 => (none) * resolution: fixed => Comment: This is still not closed as https://gitlab.haskell.org/ghc/ghc/merge_requests/146 is still not merged. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15508#comment:46> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler