> > 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. :) > > I can't get to it because parrot doesn't survive past initialization > for me. When it creates the Array PMC for userargv, it allocates the > PMC first and then the buffer for the array's data. During the > buffer's creation, it does a collection that wipes out the PMC. My > lo_var_ptr and hi_var_ptr are set to reasonable-sounding values at the > top of trace_system_stack(), but I haven't been able to track it > farther yet. Oh, and I do have your recent patch to set > interpreter->lo_var_ptr early. > > The userargv PMC is not anchored other than in the C stack, because it > dies in the pmc_new() creation process before the assignment to P0 can > run.
Weird. I had to move the lo_var_ptr initialization code to runcode instead of runops, in order to avoid collecting the ARGV pmc. The new code looks like: void *dummy_ptr; PMC *userargv; Is it possible that some systems might put dummy_ptr higher in memory than userargv, thus causing userargv to become prematurely collected? If so, there are three options: - make two dummy ptrs, and choose the lesser of the two. - set the dummy ptr to userargv, and hope we don't add two header variables. ;) - force the setting of lo_var_ptr upon the 'main' code in test_main.c, above all possible functions. I think 1 is easiest, but 3 does have the advantage of allowing the user to do GC stuff outside of the parrot execution loop, like allocating global variables (like argv, but app-specific), etc. Of course, it also imposees additional coding overhead on the embedding programmer. Mike Lambert
