Undoing the patch in resources.c seems to fix the problem.
Changing:
((Buffer *)buffer)->buflen = req_size;
to:
((Buffer *)buffer)->buflen = size;
makes it work again.
Looking into it a bit more, this seems like a 'bad' patch. Take, for
example, resize_array in array.pmc. If I call resize_array( interp, self,
1 ), my array will contain four elements (with four-byte pointers), due
to the up-rounding. When I go to GC on this, assuming these are all
PMC*'s, it's extremely possible those latter three won't be set to any
valid values.
Or another example, the 'read str int int' op in core.ops, which does:
s = string_make(interpreter, NULL, len, NULL, 0, NULL);
read($2, s->bufstart, len);
s->bufused = s->buflen;
With this uprounding change, this should be changed to len, since
s->buflen is no longer equal to len. Fixing this does not fix clint's bug.
While these two don't show the problem to clint's code, they do show that
there are issues to the uprounding that aren't cleared yet, and there are
likely to be further issues. It's safe for most string-based code, since
they only depend upon bufused, but it's not safe for buffers in general.
Oh, and here's another instance of strange behavior for clint's problem.
In the directory ./languages/BASIC/
.../../parrot out.pbc
causes the hang/crash.
While in ./
parrot languages/BASIC/out.pbc
works fine.
Go figure.
Mike Lambert
Clinton A. Pierce wrote:
> Date: 18 Apr 2002 21:50:03 -0000
> From: Clinton A. Pierce <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [netlabs #522] BASIC hangs and crashes, Win32 MSVC++, 0.0.5
>
> # New Ticket Created by "Clinton A. Pierce"
> # Please include the string: [netlabs #522]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=522 >
>
>
> Sometime during or shortly after the 0.0.5 release, BASIC broke with
> string/stack/GC errors. During program LOAD, Parrot runs off eats a ton of
> memory (sometimes) and falls over dead (eventually). Someone else in
> #parrot tried the exact same test without problems. I'm dismayed.
>
> To reproduce this bug under any post 0.0.5 CVS update:
>
> * Go into the languages/BASIC directory
> * Start basic using the handler:
> C:\projects\perl\parrot\languages\BASIC>basic.pl
> Including stackops.pasm
> Including alpha.pasm
> Including dumpstack.pasm
> Including tokenize.pasm
> Including basicvar.pasm
> Including basic.pasm
> Including instructions.pasm
> Including expr.pasm
> 4050 lines
>
> Ready
>
> * Immediately load wumpus (it won't finish):
> LOAD wumpus
> LOADING wumpus.bas...
> * Wait for segfault (it takes a couple of minutes on my P300).
> * While you're waiting, watch memory be eaten by Parrot.
>
> Calling the sweepoff and collectoff have no effect other than to make the
> memory-eating much more impressive (and the crash more spectacular). I've
> got Parrot compiled under Win32 (Win2k) with MSVC++.
>
> **
>
> I'd like to offer that BASIC could somehow be incorporated into the test
> suite for Parrot? Would it help? It's awfully sensitive to problems with
> strings, stacks, etc. As a general rule, if you can get something like
> wumpus.bas to load and run in BASIC then things are healthier than not.
>
> I could modify BASIC to help. For example, an alternate basic.pl that
> would create a "batch" version of BASIC instead of an interactive
> one. (All of the interactive code is in that short Perl script.) To run
> BASIC in batch mode is simply a matter of replacing MAIN in basic.pl with a
> MAIN that does something like:
>
> save 0 # Seed the runtime stack
> save "LOAD wumpus"
> bsr RUNLINE
> save "RUN"
> bsr RUNLINE
> restore I0 # Run's status
> end
>
> This is how my test harness works so I don't have to type programs at it,
> or wear out my capslock key.
>
>
