From: "Will Coleda" <[EMAIL PROTECTED]>
Date: Mon, 10 Mar 2008 19:43:58 -0500
[oops; continuation 0xb6926320 of type 22 is trying to jump from
runloop 15008 to runloop 1]
Before I file a bug report on the tcl code that exposes this
faux-warning[1], I wanted to double check: Is this an issue anymore
after the recent scheduler/task/event loop fixes? (The warning comes
from src/pmc/continuation.pmc)
Yes, this is the "continuation barrier" issue. It's real, it's deep,
and it's gonna require much more than a fix.
If so, can we get it upgraded to a real_exception?
It's trying to tell you that the continuation in question is about to go
to a different runloop from the one that is currently running, and that
is why your program is likely to go seriously haywire shortly afterwards
(e.g. "attempt to access code outside of current code segment"). If you
changed this to a real_exception, the exception handling code would run
into the exact same issue, which would just obscure the original
problem. In fact, it *is* the exception code that is invoking the
continuation in your case. (I tried using real_exception at this point
in continuation.pmc initially, and it only made things worse, which is
why I added the "oops" warning instead.)
If not, can we just strike the fprintf or perhaps wrap it with the
CTX_LEAK_DEBUG?
Continuing past this point can generate all sorts of badness, including
segfaults, so suppressing the message may send people on debugging wild
goose chases. You could make a case for turning this into a fatal
internal exception, though.
Regards.
[1] ./tclsh -e 'lsort --integer {10 10.2}' # just dumping this to
--pir is insufficient to reproduce the warning, though: since it's
going to be a bear to reproduce without all of tcl, I wanted a sanity
check before I did all the heavy lifting.
--
Will "Coke" Coleda
If I comment out the "push_eh" in languages/tcl/src/tclsh.pir:167, I see
a more informative backtrace:
[EMAIL PROTECTED]> ./tclsh -e 'lsort -integer {10 10.2}'
expected integer but got "10.2"
current instr.: '__integer' pc 26044
(languages/tcl/runtime/conversions.pir:173)
called from Sub '_tcl;helpers;lsort;integer' pc 22391
(languages/tcl/runtime/builtin/lsort.pir:128)
called from Sub '&lsort' pc 22274
(languages/tcl/runtime/builtin/lsort.pir:65)
called from Sub '_anon' pc 37 (EVAL_7:16)
called from Sub '_main' pc 374 (src/tclsh.pir:169)
[EMAIL PROTECTED]>
But no runloop problems, because it must no longer be trying to cross
that boundary. This means that this exception handler (also a
continuation) is almost certainly the source of the "oops" message.
Based on further testing (see backtrace below), I think the source of
the extra runloop is src/pmc/fixedpmcarray.pmc:50, which calls
Parrot_runops_fromc_args_reti to run a comparison function defined in
PIR for the quicksort. This enters an inferior runloop, from which the
error is signalled. (This is in the trunk, BTW.)
But, and assuming that this error is being signalled correctly and
should therefore be caught by tclsh, it's not at all clear how to fix
it. (Except by the ugly expedient of supporting downward-only
runloop-jumping, which I've so far avoided like the plague, since I
think implementing a partial solution will sap our interest in pursuing
a complete solution to the continuation barrier problem.)
-- Bob Rogers
http://rgrjr.dyndns.org/
------------------------------------------------------------------------
This was done by (a) reinstating the push_eh, and (b) introducing a
divide-by-zero immediately after emitting the "oops" message. (My
gdb-fu is not that good.)
[oops; continuation 0x84255e8 of type 22 is trying to jump from runloop 428 to
runloop 1]
Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1226852656 (LWP 32404)]
0xb7db7aab in Parrot_Continuation_invoke (interp=0x8052008, pmc=0x84255e8,
next=0x0) at ./src/pmc/continuation.pmc:255
(gdb) bt
#0 0xb7db7aab in Parrot_Continuation_invoke (interp=0x8052008, pmc=0x84255e8,
next=0x0) at ./src/pmc/continuation.pmc:255
#1 0xb7dbad42 in Parrot_Exception_Handler_invoke (interp=0x8052008,
pmc=0x84255e8, ex=0x82e7498) at ./src/pmc/exception_handler.pmc:103
#2 0xb7c38968 in throw_exception (interp=0x8052008, exception=0x82e7498,
dest_unused=0xb6d33818) at src/exceptions.c:567
#3 0xb7af17f8 in Parrot_tcl_error_s (cur_opcode=0xb6d33810, interp=0x8052008)
at tcl.ops:107
#4 0xb7c80c24 in runops_slow_core (interp=0x8052008, pc=0xb6d33810) at
src/runops_cores.c:213
#5 0xb7c4ca56 in runops_int (interp=0x8052008, offset=22373) at
src/interpreter.c:878
#6 0xb7c4d3f1 in runops (interp=0x8052008, offs=22373) at src/inter_run.c:104
#7 0xb7c4d6bc in runops_args (interp=0x8052008, sub=0x82f05e8, obj=0x80962c0,
meth_unused=0x0, sig=0xb7ee272c "IPP", ap=0xbfd9e28c " NB\bHMB\b<
