Re: [perl #22767] IMCC/Parrot leak and eventual segfault (partially solved)

[Clinton A. Pierce]

At 09:22 PM 6/23/2003 +0000, you wrote:
# New Ticket Created by  "Clinton A. Pierce"
# Please include the string:  [perl #22767]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22767 >
I apologize for the length of this example.  I've spent a goodly part of
this afternoon trying to track this one down and can't get a handle on a
smaller example.
Found the bug.  Mostly MEA CULPA.  A thousand pardons to the good Parrot folk.

When calling a sub like this:

        .arg 0
        call _foo
It's probably a good thing to take the 0 off the stack at some 
point.  Tends to help with the crashes.  That was my bug.  Interestingly 
enough though there still lurks a bug in Parrot somewhere.  Here's a much 
smaller test case:

.sub _main
        $P0=new PerlHash
        $P0["value"]=0
        store_global "PRINTCOL", $P0
USERLABEL_0
        .arg 0
        call  _POSIX_INKEY
        .arg 1.0
        .arg 1
        call _BUILTIN_DISPLAY
        branch USERLABEL_0
        end # (unreached)
.end
.sub _BUILTIN_DISPLAY
        saveall
        .param int argc
        .local int PRINTCOL
        .param float number
        find_global $P0, "PRINTCOL"
        set PRINTCOL, $P0["value"]
        set $P0["value"], PRINTCOL
        store_global "PRINTCOL", $P0
        restoreall
        ret
.end
.sub _POSIX_INKEY
        saveall
        $P0=new PerlHash
        global "fcntl_mode" = $P0
        restoreall
        ret
.end
This too will segfault after a while.  What's going on is the mail loop 
(USERLABEL_0) calls POSIX_INKEY and an extra INT gets left on the 
stack.  After a while, these build up and something goes haywire and *crunch*.

But watch this:

.sub _main
LOOP:
        .arg 0
        call _foo
        branch LOOP
.end
.sub _foo
        ret
.end
This suffers from the same logic bug (leaving an extra INT on the stack for 
each sub call) but *PARROT* *DOESN'T* *CRASH*.  Leaks like hell, sure, but 
no crashes.  The something about the find/store global or the new PerlHash 
in the loop causes the actual crash to happen.

[Although a suggestion.  After the crash bug gets fixed, a "stack overflow" 
error or some such nonsense being emitted from the VM might be a good 
idea.  Knowing that:

LOOP: push 0
         branch LOOP
will eventually cause a segfault makes me pine for my 6502 where:

LOOP    PHA
        JMP LOOP
Would cause the SP to spin like a top all over Page 1.  Over and over and 
over and over...  No crash, just infinite fun.  When the stack can't grow a 
nice message would help.]