On Mon, Aug 12, 2002 at 04:23:14PM -0400, Mike Lambert wrote: > 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;
You sure? That's what I thought at first too, but then I realized that (to be userargv)->vtable wasn't surviving the return from pmc_new(). So when it crashes, userargv is filled in, but at the point where GC scrozzles the PMC, userargv hasn't been assigned yet so it's address doesn't need to be within the stack range. It's actually the variable 'pmc' inside of pmc_new() that holds onto the newly-created PMC. > 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. I think anything like this will just get defeated by an optimizing compiler on some platform. > - set the dummy ptr to userargv, and hope we don't add two > header variables. ;) Ick. But since this *does* keep the problem isolated to Parrot code, it might be the way to go. If we want another variable, we can call a set_stack_top() function for each one, and it'll keep the minimum. > - force the setting of lo_var_ptr upon the 'main' code in test_main.c, > above all possible functions. I have a patch that adds an argument to Parrot_init for this purpose. > 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. Is main() even guaranteed to be early enough (assuming the order of local variable declaration doesn't determine the order of stack usage)? Actually, it's not really main(), it's whatever function creates an interpreter and calls Parrot_init(). I can easily imagine a function that creates an interpreter, creates a PMC (say a hashtable describing the application or something), does something with the PMC using the interpreter, then shuts down the interpreter. All in the same function. Describing what's wrong with this and how to avoid it is kind of complicated. (But perhaps unavoidable.)
