gc_massacre branch is ready for merging.

[Vasily Chekalkin]

Hello.

Example is not so artificial. It is what actually happening on
gc_massacre branch:

Break point to find out PMC address:

Breakpoint 1, Parrot_FileHandle_nci_open (interp=0x8051040, _self=0x20)
    at src/pmc/filehandle.c:201
201	    PMC * const _ctx         = CURRENT_CONTEXT(interp);
(gdb) n
202	    PMC * const _ccont       = Parrot_pcc_get_continuation(interp, _ctx);
(gdb)
203	    PMC * const _call_object = Parrot_pcc_get_signature(interp, _ctx);
(gdb)
214	            &_self, &filename, &got_filename, &mode, &got_mode);
(gdb)
220	    if (!Parrot_io_is_closed_filehandle(interp, _self))
(gdb) p _self
$3 = (PMC *) 0x80e1a28


Breakpoint to find out moment when PMC marked as alive. Stack frames
3,4 and 5 show that PMC address found on C stack.

Breakpoint 3, gc_ms2_mark_pmc_header (interp=0x8051040, pmc=0x80e1a28)
    at src/gc/gc_ms2.c:688
688	    ASSERT_ARGS(gc_ms2_mark_pmc_header)
(gdb) bt
#0  gc_ms2_mark_pmc_header (interp=0x8051040, pmc=0x80e1a28)
    at src/gc/gc_ms2.c:688
#1  0xb7df5188 in Parrot_gc_mark_PMC_alive_fun (interp=0x8051040,
    obj=0x80e1a28) at src/gc/api.c:157
#2  0xb7dff816 in trace_mem_block (interp=0x8051040, mem_pools=0x0,
    lo_var_ptr=3221222396, hi_var_ptr=3221221496) at src/gc/system.c:474
#3  0xb7dff400 in trace_system_stack (interp=0x8051040, mem_pools=0x0)
    at src/gc/system.c:248
#4  0xb7dff361 in trace_system_areas (interp=0x8051040, mem_pools=0x0)
    at src/gc/system.c:217
#5  0xb7dfe2c7 in Parrot_gc_trace_root (interp=0x8051040, mem_pools=0x0,
    trace=GC_TRACE_FULL) at src/gc/mark_sweep.c:227
#6  0xb7dfd1db in gc_ms2_mark_and_sweep (interp=0x8051040, flags=4)
    at src/gc/gc_ms2.c:996
#7  0xb7df6148 in Parrot_gc_mark_and_sweep (interp=0x8051040, flags=4)
    at src/gc/api.c:662
#8  0xb7da8eb1 in Parrot_sweep_ic (cur_opcode=0x80e4f44, interp=0x8051040)
    at src/ops/core_ops.c:16124
#9  0xb7e4c851 in runops_slow_core (interp=0x8051040,
    runcore_unused=0x80d9098, pc=0x80e4f44) at src/runcore/cores.c:647
#10 0xb7e4b8aa in runops_int (interp=0x8051040, offset=0)
    at src/runcore/main.c:219
#11 0xb7e0db8f in runops (interp=0x8051040, offs=0) at src/call/ops.c:127
---Type <return> to continue, or q <return> to quit---
#12 0xb7e0802b in Parrot_pcc_invoke_from_sig_object (interp=0x8051040,
    sub_obj=0x80dc580, call_object=0x80dc804) at src/call/pcc.c:324
#13 0xb7ded643 in Parrot_ext_call (interp=0x8051040, sub_pmc=0x80dc580,
    signature=0xb7f52e2e "P->") at src/extend.c:322
#14 0xb7dea3d2 in Parrot_runcode (interp=0x8051040, argc=1, argv=0xbffff4d8)
    at src/embed.c:812
#15 0xb7f2d229 in imcc_run_pbc (interp=0x8051040, output_file=0x0, argc=1,
    argv=0xbffff4d8) at compilers/imcc/main.c:415
#16 0x080490a5 in main (argc=2, argv=0xbffff4d4) at src/main.c:156

-- 
Bacek

On Thu, Sep 23, 2010 at 9:59 AM, Vasily Chekalkin <bacek at bacek.com> wrote:
> Hello.
>
> Ok guys, problem is much deeper.
>
> Imagine some code like this:
>
> void main() {
>   int z = 0xsomeaddress;
>   Parrot_run_pbc(...)
> }
>
> where PIR/PBC file contains something like this:
>
> .sub main
>  $P0 = new 'FileHandle'
>  needs_destroy $P0
>  sweep 0
> .end
>
> If address of $P0 is happen to be same as content of variable "z" from
> C code than during tracing roots in C stack GC will mark $P0 as alive
> and will not destroy it.
>
> So, current schema of timely destruction is unreliable and can't be
> used anywhere else small tests.
>
> I strongly suspect exactly this happening on Darwin/i386 and causing
> test failure.
>
> So, we should deprecate current "timely destruction" schema and design
> new one which will guarantee actual destruction of PMCs at particular
> point of time.
>
> In terms of branch merging I can just skip this test.
>
> --
> Bacek
>
>
> On Wed, Sep 22, 2010 at 9:31 PM, James E Keenan <jkeen at verizon.net> wrote:
>> Vasily Chekalkin wrote:
>>>
>>> Hello.
>>>
>>> I fixed c++ build and filehandle.t failure. I'm not sure about
>>> packfile failure on win32.
>>
>> t/pmc/filehandle.t test 22 is still experiencing the same test failure on
>> Darwin/PPC as previously reported in gc_massacre branch, updated to r49243.
>>
>> So the branch is not ready for merging.
>>
>> Thank you very much.
>> kid51
>>
>