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

Questions about "mzstkchk.h"

When I invoke a multi-threaded piece of scheme code in my
embedded MzScheme I get a segfault is is_stack_too_shallow_2().
This happens even though I have pared things down to the bare
minimum, which is just a string:

char* test = "(#%thread (#%lambda () (#%begin " ... etc..

being run by "scheme_eval_string_all":

Scheme_Object* thrd_id = scheme_eval_string_all(data, 
    scheme_get_env(scheme_config), -1);

I verified that a scheme version of this string works properly
in my SGC-build of MzScheme using the threading functionality.
However, I still get the same failure under the embedded
program as I saw in earlier iterations of this effort.

First, the program checks the stack in "is_stack_too_shallow()",
which after macro expansion on Linux (i386) with SGC looks
something like:

static int is_stack_too_shallow()
{
  unsigned long _stk_pos;
  _stk_pos = (unsigned long)&_stk_pos;

  if (STK_COMP(_stk_pos, SCHEME_STACK_BOUNDARY))
  {
    return 1;
  }
  return is_stack_too_shallow2();
}

I believe STK_COMP expands to:
   define STK_COMP(a,b) (scheme_stack_grows_up == ((a) > (b)))
and SCHEME_STACK_BOUNDARY expands to:
   scheme_stack_boundary

(gdb) p scheme_stack_grows_up
$7 = 0
(gdb) p scheme_stack_boundary
$8 = 3204501008
(gdb) p _stk_pos
$9 = 3206543056
(gdb) 

So this test fails, and we enter "is_stack_too_shallow2()":

static int is_stack_too_shallow2(void)
{
    char s[THREAD_STACK_SPACE+1];
      
    scheme_check_stack_ok(s);
    return s[THREAD_STACK_SPACE];
}

The actual SIGSEV happens at "scheme_check_stack_ok(s)", which
expands as:

static int scheme_check_stack_ok(char* s)
{
  unsigned long _stk_pos;
  _stk_pos = (unsigned long)&_stk_pos;

  if (STK_COMP(_stk_pos, SCHEME_STACK_BOUNDARY))
  {
    s[THREAD_STACK_SPACE] = 1;
  } else {
    s[THREAD_STACK_SPACE] = 0;
  }
}

So for some reason this code is triggering the exception,
before scheme_check_stack_ok is actually entered.  The
funny thing is that the "mzscheme" executable I built
using SGC can handle threading just fine.

Aside from the code in my program that establishes the stack base:

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

... and the initial call to scheme_basic_env(), are there any
other initializiations that might be missing?  This feels to
me as if it were the fault of some kind of initialization
problem with respect to the SGC's understanding of the stack:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4101 (LWP 4923)]
0x4022ec4e in is_stack_too_shallow2 () at ./process.c:1610
1610      scheme_check_stack_ok(s);
(gdb) bt
#0  0x4022ec4e in is_stack_too_shallow2 () at ./process.c:1610
#1  0x4022ec75 in is_stack_too_shallow () at ./process.c:1620
#2  0x4022ece7 in scheme_thread_w_manager (thunk=0x40311530, 
    config=0x402cf270, mgr=0x0) at ./process.c:1669
#3  0x4022eade in scheme_thread (thunk=0x40311530, config=0x402cf270)
    at ./process.c:1525
#4  0x4022eb12 in sch_thread (argc=1, args=0x402e6e38) at ./process.c:1535
#5  0x40208500 in scheme_do_eval (obj=0x4032a638, num_rands=1, 
    rands=0x402e6e38, get_value=1) at ./eval.c:2592
#6  0x40208b2c in eval_k () at ./eval.c:2997
#7  0x4020d555 in scheme_top_level_do (k=0x40208a8c <eval_k>, eb=1)
    at ./fun.c:883
#8  0x40208b83 in _eval (obj=0x40311538, isexpr=0, multi=0, top=1)
    at ./eval.c:3014
#9  0x40208b9c in scheme_eval_compiled (obj=0x40311538) at ./eval.c:3021
#10 0x40208a63 in scheme_eval (obj=0x4032fe18, env=0x40339058) at ./eval.c:2958
#11 0x402090c4 in scheme_eval_string_all (
    str=0x81b3038 "(#%thread (#%lambda () (#%begin (begin \n(display \"Content-type: text/html\")\n(newline)\n(newline)\n(display \"<HTML><HEAD>\")\n(display \"<TITLE>Big Fun Test</TITLE>\")\n(display \"<BODY><H1>Another Exciting Mo"..., 
env=0x40339058, cont=-1) at ./eval.c:3276
#12 0x401ffc33 in handle_request (request=0x8150298) at mv_interps.cc:322
#13 0x401fff22 in Run (arg=0x8162700) at mv_interps.cc:406
#14 0x811910b in NsThreadMain ()
#15 0x4002bc95 in pthread_start_thread () from /lib/libpthread.so.0
#16 0x4002bcdd in pthread_start_thread_event () from /lib/libpthread.so.0

What am I missing?  I've gone over the "main.c" for MzScheme, and
looked over "process.c" and a few other files.  Obviously something
is different about my startup environment (which is most likely due
to the fact that a subthread of another program is actually starting
the interpreter) but I'm just not sure where else to look.

Help!

Thanks,

-Brent