So, it's possible for someone to crash parrot by writing questionable PIR? ^_^
(This was working fine for quite some time, btw.)
Also, what do I need to do to save these subroutines? I'm doing dynamic dispatch based on the tcl commands, so
proc foo {} {
puts "foo"
}defines a sub in parrot's "Tcl" namespace called "foo".
When I want to execute this sub later, I do a find_global "Tcl", "foo", then invoke what I get back.
So, if defining a subroutine isn't sufficient to avoid the subroutine from getting garbage collected, what do you recommend? Is this /just/ because I'm using pir_compiler? could I expect the same thing to happen to subs that are defined in the "Tcl" namespace at the time the interpreter is begun?
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
Running the tcl "examples/bench.tcl" script, I get the following backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory. 0x0021cb38 in Parrot_Sub_invoke (interpreter=0xd001a0, pmc=0xed2b60, next=0xf20284) at classes/sub.c:239 239 if (interpreter->code->cur_cs != sub->seg) {
Any chance this is a parrot issue and not a tcl issue?
It's GC related (running it with -G succeeds).
It seems that you aren't always storing compiled code objects away. So these get GCed. E.g.
commands/proc.imc:106
$P0 = compile pir_compiler, proc_body
The compilation result C<$P0> remains unanchored.
leo
