[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about "mzstkchk.h"



On Sun, Jan 21, 2001 at 08:53:14AM -0800, Matthew Flatt wrote:
> Quoting Brent Fulgham:
> > When I invoke a multi-threaded piece of scheme code in my
> > embedded MzScheme I get a segfault is is_stack_too_shallow_2().
> 
> Sorry that I haven't replied to your earlier messages sooner. I haven't
> had time to look into it and figure out a useful question.
> 

No problem.  It gave me a chance to try a few alternatives.  Eventually
with enough prodding the underlying problem will become obvious.

> > (gdb) p scheme_stack_grows_up
> > $7 = 0
> > (gdb) p scheme_stack_boundary
> > $8 = 3204501008
> > (gdb) p _stk_pos
> > $9 = 3206543056
> 
> scheme_stack_boundary should be close to _stk_pos (much closer than the
> above numbers). It looks like the registered stack base is for a
> different (OS-level) thread than the current one.
> 
> scheme_stack_boundary *should* have the same value as the one supplied
> to GC_set_stack_base(). Can you check that it does?
> 

Okay.  I put a breakpoint in so I could recreate the above point in
the processing:

(gdb) p scheme_stack_grows_up
$1 = 0
(gdb) p scheme_stack_boundary
$2 = 3204501004
(gdb) p _stk_pos
$3 = 3206543056
(gdb) p mzscheme_stack_start
No symbol "mzscheme_stack_start" in current context.
(gdb) return

... afeter bubbling back up to my Run() thread (which is the
long-lived thread that manages MzScheme) I can check:
(gdb) p mzscheme_stack_start
$5 = (void *) 0xbf1ffabc
(gdb) p (unsigned long)mzscheme_stack_start
$7 = 3206544060
(gdb) 

So this looks *way* off.  I wonder why?

> Also, just to make sure: GC_set_stack_base() is called with the address
> of a stack variable (i.e.: not static) in the same OS-level thread as
> the one that crashes?
> 

This should be true.  Here's the rough sequence of events:

1.  AOLserver starts up, and reads its configuration file.  This
    instructs it to load certain add-on modules, such as the
    MzScheme runtime.

2.  AOLserver's "main" thread enters the startup code for the
    MzScheme runtime, which creates a new OS-level thread that
    starts running a routine called "Run()", then it returns
    and AOLserver goes on to load other modules, etc.

3.  When Run() starts, it performs the following initialization:

// Fire up the interpreter
void Run(void* arg)
{
  Ns_Log(Notice, "MachV:  Setting basic environment.");

  #if defined(MZ_STACK_START_HACK) || defined(USE_SENORA_GC)
  void* mzscheme_stack_start = NULL;
  long start2;
  mzscheme_stack_start = (void*)(&start2);
  GC_set_stack_base(mzscheme_stack_start);
  #endif

  MV_InterpreterPool* interp = (MV_InterpreterPool*)arg;
  interp->SetParentEnv(scheme_basic_env());
  Ns_ThreadSetName("MachV Intrp Svr");
			      
  // Ready for business!
  Ns_Log(Notice, "MachV:  Interpreter Server Active.");

  // Wait for signals
  while (1)
  {

... from here on it's just a server waiting for request to
evaluate scheme s-expressions.

The top few lines set the GC stack base, and they are taken
pretty much verbatin from MzScheme's "main.c".

Anything else I can check?

Thanks,

-Brent