[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