From: Leopold Toetsch <[EMAIL PROTECTED]>
   Date: Sun, 12 Feb 2006 11:51:35 +0100

   On Feb 12, 2006, at 5:30, Bob Rogers wrote:

   > parrot: src/inter_call.c:899: process_args: Assertion `idx >= 0' 
   > failed.

   The backtrace shows argument passing to an exception handler and it 
   looks like the same bug that made tcl's cmd_global_2 failing.

   The 'idx := -1' indicates that there is still a case, where the
   register allocator doesn't assign a register to the message S-reg of
   an exception handler:

      handler:
        get_results '(2,1)', Px, Sy

Aha; that makes things a lot clearer.  But this could be a feature . . .

   To track that down further I'd need a 'grep -2' of all exception 
   handler 'get_results' in your code. A workaround is to just use the 
   message argument in the handler e.g.

      $S99 = Sy

   leo

There is essentially only one of these [1].  The original code looks
like this:

        main_exception:
                .local pmc exception
                .get_results (exception)
                print "Error: "
                print exception

After updating, this resulted in "too many arguments passed (2) - 1
params expected" errors, so I had changed it to the following:

        main_exception:
                .local pmc exception
                .local string message
                .get_results (exception, message)
                print "Error: "
                print exception

This is what failed on me last night, but I find that this no longer
fails, even though I am using the identical Parrot build.  I was
planning to send you the whole sub, in the hope that it would help track
down the register allocator problem, but that is now rather pointless.
And I don't even have the exact version of the whole source file I was
using last night; I threw away a debugging aid too soon.  But this was
just a __get_string method for debugging; I redid all of the other
changes I had made to the :main sub (which contains the 'main_exception'
handler), to the best of my recollection, but still couldn't reproduce
the error.  So, FWIW, it looks like there may be some bad state carried
over from one invocation of the register allocator to the next.

   However, there is a sense in which "register -1" could be a feature.
If the arg-passing code treats these as args/returns that are ignored,
then it doesn't have to pay the cost of conversion and assignment, and
the unused return value might then be GC'ed earlier as a consequence.  A
register of -1 with the :slurpy bit set should do nicely to avoid
allocating unused slurpy arrays, as discussed earlier.  Though, of
course, this requires some PIR syntax in order to be used explicitly.
Perhaps ":ignore" or ":ignored" as a register name?

   In any case, thanks for getting me unstuck, and sorry I couldn't have
been of more help in tracking what's actually happening in the register
allocator -- especially since doing so is required for featurizing it!

                                        -- Bob

[1]  There is one other push_eh in the code, but it doesn't point to
     get_results; it exists in order to ignore recursive errors in error
     handling code.  But that sub isn't called in this case.

Reply via email to