newclass bug, or something
Luke Palmer
.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
Leopold Toetsch
> 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
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.
> It runs fine if I C<sweepoff> at the beginning, and indeed,
$ parrot -G x.imc # turn off DOD
Thanks for reporting,
leo
Michal Wallace
Luke Palmer wrote:
> This patch re-implements the register backing stacks as PObjs (so
> they can be garbage-collected), honors their COW flags, and adds
> them to the interpreter context (where they should be, honest!).
>
> As a healthy side-effect, it encapsulates their behavior nicely into
> register.c, when before their guts were splattered all over the
> source.
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/
--------------------------------------
Luke Palmer
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
Michal Wallace
> @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).
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?
Leopold Toetsch
> .sub __main__
> newsub $P0, .Closure, _func
> savetop
No - not for plain subroutines/closures.
> 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.
Yep.
> Luke
leo
Luke Palmer
> On Thu, 8 Jan 2004, Luke Palmer wrote:
> > .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).
>
>
> 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?
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
Leopold Toetsch
> newsub $P1, .Continuation, done
For returning just use a .RetContinuation. Or still better, just omit
$P1 totally here:
> .pcc_call $P0, $P1
leo
Michal Wallace
Aha! I like that even better. :) Thanks!
Michal Wallace
> 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.
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. :)
Dan Sugalski
>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?
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