Mike, I tried to have a look at the lexicals and subs issues but I am finding that with the GC_DEBUG flag set to 1, I *always* get a segmentation fault, even for simple pasm files like :
set I0, 12 end or just: end Is there something I am doing wrong? I did a fresh checkout about an hour ago. ??? --- Jonathan Sillito On Mon, 2002-08-12 at 01:56, Mike Lambert wrote: > Hey, > > I re-added the GC_DEBUG define today, and weeded out a bunch of issues. > For those who don't remember, GC_DEBUG (currently in parrot.h) causes > various limits and settings and logic to be setup such that GC bugs occur > relatively soon after the offending code. It allocates one header at > a time, and performs DOD and collection runs extremely frequently > (effectively, anywhere they could possibly occur if GC_DEBUG weren't > defined.) It's goal is to make GC bugs which appear only in complex > programs...appear in simpler ones as well. > > Check the cvs-commit traffic if you're interested in what issues I've > fixed already. From what I can tell, two things remain: > - regexes (these are known to be broken. angel's latest patch should fix > these in theory. Probably not worth spending time on fixing these.) > - hashes (these were recently rewritten to use indices, a step forward, > but they aren't 100% clean yet) > - lexicals (there's one remaining issue on the last test I didn't look > into) > - subs (likely includes all variety of them. Basically, I got the wrong > result on one test, instead of GPF failures like I received on the above > bugs.) > - possibly other that got lost in the noise of the above issues > > Anyone more well-versed in these departments than I care to take a look at > the potential problems? Just change GC_DEBUG in parrot.h, and you can be > on your way. :) > > Thanks, > Mike Lambert
