The following program segfaults after 510 iterations:

    .sub _main
        $I0 = 0
    again:
        $S1 = "anon"
        $S0 = $I0
        inc $I0
        concat $S1, $S0
        newclass $P0, $S1
        find_type $I2, $S1
        print $I2
        print "\n"
        if $I0 < 1000 goto again
        end
    .end

It runs fine if I C<sweepoff> at the beginning, and indeed, it dies
during DOD, since bucket points to an invalid memory location.  I
haven't the slightest clue what's wrong beyond that.

Here's the gdb backtrace:

#0  0x080809d2 in mark_hash (interpreter=0x826f9b0, hash=0x8dfb38) at src/hash.c:297
297                     (hash->mark_key)(interpreter, (PObj *)bucket->key);
(gdb) bt
#0  0x080809d2 in mark_hash (interpreter=0x826f9b0, hash=0x8dfb38) at src/hash.c:297
#1  0x081cfabb in Parrot_PerlHash_mark (interpreter=0x826f9b0, pmc=0x8dfb50) at perlhash.c:62
#2  0x081fefcf in Parrot_OrderedHash_mark (interpreter=0x826f9b0, pmc=0x8dfb50) at orderedhash.c:57
#3  0x080b764c in trace_children (interpreter=0x826f9b0, current=0x8dfb50) at src/dod.c:251
#4  0x080b74ea in trace_active_PMCs (interpreter=0x826f9b0, trace_stack=1) at src/dod.c:201
#5  0x080b7cad in Parrot_do_dod_run (interpreter=0x826f9b0, trace_stack=1) at src/dod.c:744
#6  0x081f0ba7 in more_traceable_objects (interpreter=0x826f9b0, pool=0x8277170) at src/smallobject.c:71
#7  0x081f0cbc in get_free_object (interpreter=0x826f9b0, pool=0x8277170) at src/smallobject.c:134
#8  0x080b66a7 in get_free_buffer (interpreter=0x826f9b0, pool=0x8277170) at src/headers.c:55
#9  0x080b6be6 in new_bufferlike_header (interpreter=0x826f9b0, size=60) at src/headers.c:250
#10 0x08080f46 in new_hash_x (interpreter=0x826f9b0, hptr=0x8dfb50, val_type=enum_type_PMC, val_size=0,
    hkey_type=Hash_key_type_ascii, compare=0x8080565 <STRING_compare>, keyhash=0x8080518 <key_hash_STRING>,
    mark=0x80b71d8 <pobject_lives>) at src/hash.c:516
#11 0x08080f05 in new_hash (interpreter=0x826f9b0, hptr=0x8dfb50) at src/hash.c:477
#12 0x081cfa92 in Parrot_PerlHash_init (interpreter=0x826f9b0, pmc=0x8dfb50) at perlhash.c:55
#13 0x081fefa5 in Parrot_OrderedHash_init (interpreter=0x826f9b0, pmc=0x8dfb50) at orderedhash.c:50
#14 0x0807ed8a in pmc_new (interpreter=0x826f9b0, base_type=23) at src/pmc.c:51
#15 0x081ecfd0 in Parrot_new_class (interpreter=0x826f9b0, class=0x8dfbb0, class_name=0x9a7e70) at src/objects.c:131
#16 0x080cefda in Parrot_newclass_p_s (cur_opcode=0x8291608, interpreter=0x826f9b0) at object.ops:123
#17 0x0807e1c5 in runops_slow_core (interpreter=0x826f9b0, pc=0x8291608) at src/runops_cores.c:115
#18 0x080753b3 in runops_int (interpreter=0x826f9b0, offset=0) at src/interpreter.c:628
#19 0x08075455 in runops_ex (interpreter=0x826f9b0, offset=0) at src/interpreter.c:650
#20 0x08075606 in runops (interpreter=0x826f9b0, offset=0) at src/interpreter.c:701
#21 0x080b0ad5 in Parrot_runcode (interpreter=0x826f9b0, argc=1, argv=0xb8dcf16c) at src/embed.c:513
#22 0x08074611 in main (argc=1, argv=0xb8dcf16c) at imcc/main.c:548
#23 0x00232ba7 in __libc_start_main () from /lib/libc.so.6

gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)

Luke

Yep. Tricky. The init code of OrderedHash didn't clear the ptr, where
the hash isn't yet constructed. Now during DOD this pointer was marked
as a PerlHash which caused the segfault.

$ parrot -G x.imc   # turn off DOD

Thanks for reporting,
leo

Hey Luke,

I applied this patch, ran make realclean and rebuilt parrot.
All the parrot tests pass (except the two about numbers, and I
think they were failing before) but it doesn't like the code
that pirate's generating. I boiled the problem down to this:

#######
.sub __main__
    newsub $P0, .Closure, _func
    newsub $P1, .Continuation, done
    .pcc_begin non_prototyped
    .pcc_call $P0, $P1
done:
    .local object result
    .result result
    .pcc_end
    print result
    print "\n"
    end
.end

.pcc_sub _func non_prototyped
    .local object res
    res = new PerlString
    res = "hello!"
    .pcc_begin_return
    .return res
    .pcc_end_return
.end
########

When I run this, parrot says:

    No more I register frames to pop!

I think the problem is coming from the .pcc_begin_return
line. This code works fine if I change the .Continuation to
a .Closure or .Coroutine... It also worked before the patch.
Do I have my calling conventions screwed up or is this a bug?

Sincerely,

Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------

Your calling conventions are screwed up.  I'm glad this failed, as I was
anticipating this failure and it didn't come up anywhere in the tests!  

If you unroll what .pcc_call is doing, you might see the problem:

    .pcc_begin non_prototyped
    .pcc_call $P0, $P1
done:
    .local object result
    .result result
    .pcc_end

Turns into:

@pcc_sub_call_4:
        set P0, P17
        set P1, P16
        set I0, 0
        set I1, 0
        set I2, 0
        set I3, -2
        updatecc
        savetop
        invoke
done:
        restoretop
        set P16, P5

When the continuation is invoked, that savetop it just did is completely
nullified, and you're back to the state before you created the
continuation.  So, in order to get this to work properly, your first
four lines must be:

.sub __main__
    newsub $P0, .Closure, _func
    savetop
    newsub $P0, .Continuation, done

So the restoretop after the invoke has something to pop (and so your
register state isn't screwed up when you get back).

Or you could do as PCC does and use a .RetContinuation, which doesn't
close over the stacks, when you don't actually need a full continuation.

Hope this helped,

Luke

Thanks Luke.

I changed my compiler to call savetop before every function
call, and that passes my tests but I'm having trouble
visualizing why. Would I ever NOT want to call savetop
before creating a continuation?

Sincerely,

Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------

No - not for plain subroutines/closures.

Yep.

leo

Very rarely would you not savetop before creating a *real* continuation.
But again, very rarely would you actually create a *real* continuation
(depending on your language).  RetContinuations are almost always a
better choice for traditional languages, and languages like Python with
no support for continuations.

You won't get in trouble mixing RetContinuations with real ones, as long
as you don't try to use RetContinuations like Continuations, and only
use them to return downward.

Luke

For returning just use a .RetContinuation. Or still better, just omit
$P1 totally here:

leo

Aha! I like that even better. :) Thanks!

Sincerely,

Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------

Gotcha. It just looked odd to me that you had to call
savetop... But now I see that's because I was doing the
wrong thing all along. :)

Sincerely,

Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------

At 1:02 AM -0500 1/9/04, Michal Wallace wrote:

Sure. The only reason to call savetop is if you want to save R16-31
of all four register sets. The only reason you'd do this is if you
actually *care* about the contents of those four sets. If you don't
care about one or more set, for example because your code is entirely
PMC based and thus doesn't use the I, S, or N registers, you wouldn't
-- it's a waste.

Also, if your compiler's code analysis determines that none of the
registers of a particular set are read without a previous write, then
there'd be no reason to save that set. It's a matter of tracking
register content lifetimes -- if all the registers in a set are
effectively dead there's no reason to preserve the contents on the
stack.
--
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk