Re: [GHC] #15508: concprog001 fails with various errors

4 Jan 2019

      #15508: concprog001 fails with various errors
-------------------------------------+-------------------------------------
        Reporter:  osa1              |                Owner:  osa1
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.8.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, Phab:D5178
-------------------------------------+-------------------------------------

Comment (by osa1):

 Looking at the assembly for `returnToStackTop`, we're loading a TSO's
 `prof`
 field to `rCCCS` so the problem is with the `prof` field of a TSO.
 Debugging
 further, here's where we first update `prof` field of a TSO with the
 problematic
 value (0x4207528000):

 {{{
 Thread 2 hit Hardware watchpoint 6: ((StgTSO *) 0x420019d7e0)->prof.cccs

 Old value = (CostCentreStack *) 0x4207528000
 New value = (CostCentreStack *) 0xb44390
 0x0000000000a37819 in stg_returnToSched ()
...
...
...
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