crashing parrot for fun and profit.
William Coleda
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) {
(gdb) bt
#0 0x0021cb38 in Parrot_Sub_invoke (interpreter=0xd001a0, pmc=0xed2b60, next=0xf20284) at classes/sub.c:239
#1 0x00067d74 in Parrot_invokecc (cur_opcode=0xf20280, interpreter=0xd001a0) at ops/core.ops:440
#2 0x001d617c in runops_slow_core (interpreter=0xd001a0, pc=0xf20280) at src/runops_cores.c:147
#3 0x00048e90 in runops_int (interpreter=0xd001a0, offset=0) at src/interpreter.c:742
#4 0x00042aa8 in runops (interpreter=0xd001a0, offs=0) at src/inter_run.c:81
#5 0x00015750 in Parrot_runcode (interpreter=0xd001a0, argc=2, argv=0xbffffce4) at src/embed.c:768
#6 0x00015508 in Parrot_runcode (interpreter=0xd001a0, argc=2, argv=0xbffffce4) at src/embed.c:700
#7 0x00003f18 in main (argc=2, argv=0xbffffce4) at imcc/main.c:603
Any chance this is a parrot issue and not a tcl issue?
I'm also seeing the following on a slightly different tcl script:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x000625a8 in Parrot_find_global_p_sc_sc (cur_opcode=0xd2235c, interpreter=0xd001a0) at ops/var.ops:305
305 if (!$2)
(gdb) bt
#0 0x000625a8 in Parrot_find_global_p_sc_sc (cur_opcode=0xd2235c, interpreter=0xd001a0) at ops/var.ops:305
#1 0x001d617c in runops_slow_core (interpreter=0xd001a0, pc=0xd2235c) at src/runops_cores.c:147
#2 0x00048e90 in runops_int (interpreter=0xd001a0, offset=0) at src/interpreter.c:742
#3 0x00042aa8 in runops (interpreter=0xd001a0, offs=0) at src/inter_run.c:81
#4 0x00015750 in Parrot_runcode (interpreter=0xd001a0, argc=2, argv=0xbffffce4) at src/embed.c:768
#5 0x00015508 in Parrot_runcode (interpreter=0xd001a0, argc=2, argv=0xbffffce4) at src/embed.c:700
#6 0x00003f18 in main (argc=2, argv=0xbffffce4) at imcc/main.c:603
Leopold Toetsch
> 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
William Coleda
(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
> So, it's possible for someone to crash parrot by writing questionable PIR? ^_^
Yes. It's assembler programming basically. But eventually we'll have to
set GCed items in such a way that an access doesn't segfault but throws
an exception.
> (This was working fine for quite some time, btw.)
Yes. Recent changes to compile caused a different behavior.
I've already asked a few times about the wanted default behavior of
compiled code subroutines.
.sub sub1
...
.sub sub2
...
Should compile return the first sub as the result?
.sub sub1 @ANON
...
.sub sub2 @MAIN, @ANON
...
This should return 'sub2' and not install the globals. How is 'sub1'
kept alive and how long?
Currently in all cases a *new* Eval object is returned, which represents
the compiled code. It overlaps the first compiled subroutine - both have
the same start address. And this returned object has to be kept alive.
> Also, what do I need to do to save these subroutines?
See above.
leo