oops, I meant to copy this to the list so we can get some feedback going. On Sat Apr 25 11:37:47 2009, Whiteknight wrote: > On Wed Oct 15 23:32:11 2008, allison wrote: > > On Wed Oct 15 12:42:23 2008, coke wrote: > > > Here's yet another updated version (this time for the exception handler) > > > of the test that doesn't segfault, but still generates incorrect output > > > (generates both an OK line and a NOK line) > > > > It looks like the exception handler is resuming after the exception is > > handled. (Resuming by default, instead of only resuming when the resume > > continuation is explicitly invoked.) > > Quite a tricky little problem! I've been staring at this in the debugger > for a while, and I think I have a good idea about what's happening. > > First, the resume continuation is not being invoked by default. > > The new op calls Parrot_Class_instantiate, which calls > src/pmc/class.pmc:initialize_parrots, which calls > Parrot_pcc_invoke_from_sig_object, which in turn calls runops(), which > creates a new runloop (runloop 2). > > The exception is thrown--and handled--in runloop 2. The end opcode is > hit, which calls HALT(). runops() exits, returns to > Parrot_pcc_invoke_from_sig_object, which returns control back to the > first runloop, and execution continues like normal from that point. > > The good news: this is very fixable > The bad news: We need to decide which is the best way to do it. > > I notice immediately that runops_slow_core (and the other cores) return > a opcode_t* offset value that is ignored in runops_int, and then isn't > returned up the call chain. HALT() returns (opcode_t*)0, so it might be > useful to capture that somewhere along the way and jump to Parrot_exit() > if we catch it. However, I also notice that Parrot_returncc (and > probably other return variants) jumps back to address 0 when called from > within Parrot_pcc_invoke_from_sig_object (and probably all other related > calling functions as well). > > So here are some options: > 1) Salt these embedded runloops so that normal return and returncc calls > return a different address then an end call does. if return and returncc > had jumped to location OPCODE_T_MAX (which is a good nonsensical pc > value), and the end opcode had a dest of 0 (which doesn't change the > current behavior of HALT), then we could capture the different return > values up the call chain and call Parrot_exit directly in runops_int or > someplace when we detect a HALT. > 2) Change the behavior of the "end" opcode to call Parrot_exit directly, > instead of returning an (opcode_t*)0 and letting the call chain unwind > itself a little bit before calling it. Similarly, do a quick longjump > back up the call chain to a place that will perform all the necessary > atexit routines before exiting, or whatever we need > > As soon as we figure out a good way forward, we can get this issue all > fixed up. >
-- Andrew Whitworth a.k.a Whiteknight _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
