Re: guile-2.0 on mingw: the sequel

[Eli Zaretskii]

> Date: Sat, 24 Aug 2013 10:05:13 +0200
> From: Panicz Maciej Godek <address@hidden>
> Cc: "address@hidden" <address@hidden>
> 
> 2013/8/24 Eli Zaretskii <address@hidden>
> 
> > > yes, it seems that this was the reason. So now the guile
> > > interpreter runs properly, but I still have a problem with
> > > running a program that, having been linked against
> > > libguile, would call scm_with_guile or scm_init_guile, e.g.
> > > ===
> > > #include <libguile.h>
> > > void hi(void *unused) { scm_puts("hello!\n", scm_current_output_port());
> > }
> > > int main() {
> > >    scm_with_guile(hi, NULL);
> > >   return 0;
> > > }
> > > ===
> >
> > Does this work on other platforms?  (I know almost nothing about
> > linking C programs with libguile; maybe your program has a bug, or you
> > are missing some function call necessary for this to work?)
> >
> >
> It's the simplest example I could come up with.
> The same code executes properly (i.e. displays "hello!") on linux.

I guess you didn't configure without threads on GNU/Linux, did you?
If not, I suggest to try that, my impression is that Guile without
threads is not used too much on Posix platforms.

Anyway, I looked into this a bit.  I can confirm that the simple
program you mentioned the first time aborts due to "stack overflow"
(the blurb about "application requesting runtime to terminate in an
unusual way" is displayed when the application calls 'abort').
However, I think this is a bogus result of what was supposed to be a
test for stack overflow.  Here are the details:

If I set a breakpoint in 'abort', I see this backtrace:

     #0  0x004c58d0 in abort ()
     #1  0x004257ff in pre_init_throw ()
     #2  0x0045903e in vm_regular_engine ()
     #3  0x0045aca7 in scm_call_with_vm ()
     #4  0x004254df in scm_throw ()
     #5  0x00404f37 in scm_error_scm ()
     #6  0x00404fa7 in scm_error ()
     #7  0x004391ef in scm_report_stack_overflow ()
     #8  0x0045abf1 in scm_c_vm_run ()
     #9  0x0045af17 in scm_load_compiled_with_vm ()
     #10 0x0043c1e0 in scm_primitive_load_path ()
     #11 0x00404af6 in scm_load_startup_files ()
     #12 0x00404e5c in scm_i_init_guile ()
     #13 0x00402344 in scm_i_init_thread_for_guile ()
     #14 0x00402519 in scm_init_guile ()
     #15 0x004013c0 in main () at guile-hello.c:13

The stack check, SCM_CHECK_STACK, called by scm_c_vm_run, tests the
current stack pointer against the stack base and stack limit.  What I
see is that the stack base of the main (and only) thread is zero,
which of course will always fail any such test.

Stepping through the initialization code code in scm_i_init_guile
(specifically, guilify_self_1, where the first thread is recorded,
including its stack base), it turns out that GC_get_stack_base, which
is implemented in libgc, returns zero as the stack base.  The rest is,
as they say, history.  I didn't have a debug build of libgc to step
into its code, so I couldn't see what is going on there, and libgc has
too many different implementations of GC_get_stack_base to guess from
the sources which one is actually compiled in, and what goes wrong
there.  Perhaps you could step into GC_get_stack_base that on your
system.

Alternatively, a possible workaround is to disable stack checking,
using scm_debug_options.  I'm quite sure there's nothing wrong with
the stack.

In any case, the Guile that is built _is_ functional: I've built GNU
Make with Guile support using it, and the resulting make.exe passes
all the tests that exercise the Guile interface, which include
invoking the Guile interpreter to evaluate expressions.