[plt-scheme] embedded MzScheme not started on main thread

From: Scott Walters (scott at integra-online.com)
Date: Tue Sep 3 10:52:42 EDT 2002

Thanks for the info.  I found the problem.  When 
I switched from building my code into a static 
library to building it into a DLL, the DllMain 
function from the gc project was executing and 
initializing the gc before my code had a chance 


9/2/2002 7:59:16 PM, Matthew Flatt 
<mflatt at cs.utah.edu> wrote:

>  For list-related administrative tasks:
>    http://list.cs.brown.edu/mailman/listinfo/pl
>At Mon, 26 Aug 2002 17:27:18 -0600, Scott 
Walters wrote:
>> I'm not really very knowledgeable about how 
>> gc works but it seems like I would have to set 
>> the stack bottom for the MzScheme initializing 
>> thread to the address of a procedure variable 
>> inside a function that would not be returned 
>> until the thread died.  Is this right?  
>> If it is, 
>> I'm not sure how it can work in my setup since 
>> the Java servlet container controls the code 
>> the thread initially executes so I don't 
>> know where the stack bottom is by the time my 
>> Java code is invoked. Do you know of a way I 
>> find out for Win32?
>It doesn't have to be the actual stack bottom. 
Just something "below"
>the part of the stack used for Scheme code.
>> Also, does the gc store a stack bottom for all 
>> threads.  I assume it must but I guess this is 
>> handled by the MzScheme code. Does this affect 
>> what I have to do to set the stack bottom?
>There's one stack bottom, since MzScheme will 
work with only one thread
>at any given time.
>> First, I tried starting a C thread that sets 
>> GC_stackbottom to the address of a procedure 
>> variable, initializes scheme and then waits 
>> indefinitely.
>That should have worked, so I think something 
else is going wrong.
>> When this didn't work,  I tried 
>> setting the GC_USE_DLL compile flag on the gc 
>> since this is how it's ultimately ending up 
>> though the dll I build is statically linking 
>> MzScheme.  Is this correct?
>I think you don't want GC_USE_DLL, but I forget 
the subtleties of v103.
>> It bombs in the last line of the 
>> following function because the hhdr variable 
>> null.  Does this suggest anything?
>> GC_bool GC_is_marked(p)
>> ptr_t p;
>> {
>>     register struct hblk *h = HBLKPTR(p);
>>     register hdr * hhdr = HDR(h);
>>     register int word_no = (word *)p - (word 
>>     return(mark_bit_from_hdr(hhdr, word_no));
>> }
>Offhand, I'd guess that the GC's own data 
structures are getting
>collected, which might mean that the GC is 
having trouble finding the
>address of static variables.
>In other words, the problem may have less to do 
with finding the stack
>than finding static variables.

Posted on the users mailing list.