Re: guile-2.0 on mingw: the sequel

[Eli Zaretskii <eliz@gnu.org>]

> From: Mark H Weaver <mhw@netris.org>
> Cc: Panicz Maciej Godek <godek.maciek@gmail.com>,  guile-user@gnu.org
> Date: Sun, 25 Aug 2013 12:59:43 -0400
> 
> > Anyway, I looked into this a bit.  I can confirm that the simple
> > program you mentioned the first time aborts due to "stack overflow"
> [...]
> > [...] it turns out that GC_get_stack_base, which
> > is implemented in libgc, returns zero as the stack base.
> 
> Thanks for looking into this, Eli!
> 
> This raises the question: what's the relevant difference between
> Panicz's simple 'main' and Guile's 'main' (in libguile/guile.c) that
> causes one to (apparently) initialize the stack base properly, where the
> other fails?  It would be worthwhile to find out.

Thanks for the suggestion, here's some follow-up:

Comparison between libguile/guile.exe and the test program shows that
the former goes through a different initialization process, calling
libgc as part of it.  Here's the call stack from guilify_self_1, when
called from libguile/guile.exe:

     Breakpoint 1, guilify_self_1 (base=base@entry=0x28fe8c) at threads.c:533
     533     {
     (gdb) n
     541       t.pthread = scm_i_pthread_self ();
     (gdb) n
     542       t.handle = SCM_BOOL_F;
     (gdb) p t.pthread
     $1 = 0
     (gdb) bt
     #0  guilify_self_1 (base=base@entry=0x28fe8c) at threads.c:542
     #1  0x004330b7 in scm_threads_prehistory (base=base@entry=0x28fe8c)
	 at threads.c:2176
     #2  0x00412c2d in scm_i_init_guile (base=base@entry=0x28fe8c) at init.c:386
     #3  0x0043249c in scm_i_init_thread_for_guile (base=0x28fe8c,
	 parent=<optimized out>) at threads.c:835
     #4  scm_i_init_thread_for_guile (base=0x28fe8c, parent=<optimized out>)
	 at threads.c:814
     #5  0x004324c4 in with_guile_and_parent (base=0x28fe8c, data=0x28feb4)
	 at threads.c:901
     #6  0x709cae6f in ?? () from D:\usr\bin\libgc-1.dll
     #7  0x004326cc in scm_i_with_guile_and_parent (parent=<optimized out>,
	 data=0x28fee0, data@entry=0x28feb0,
	 func=func@entry=0x412abc <invoke_main_func>) at threads.c:951
     #8  scm_with_guile (func=func@entry=0x412abc <invoke_main_func>,
	 data=data@entry=0x28fee0) at threads.c:957
     #9  0x00412beb in scm_boot_guile (argc=argc@entry=1,
	 argv=argv@entry=0x28c6970,
	 main_func=main_func@entry=0x4013d4 <inner_main>,
	 closure=closure@entry=0x0) at init.c:320
     #10 0x004c5eab in main (argc=1, argv=0x28c6970) at guile.c:108
     (gdb) p t.base
     $2 = (SCM_STACKITEM *) 0x28fe8c

while the latter does not go through libgc:

     Breakpoint 1, guilify_self_1 (base=base@entry=0x2deff0c) at threads.c:533
     533     {
     (gdb) bt
     #0  guilify_self_1 (base=base@entry=0x2deff0c) at threads.c:533
     #1  0x00402f5f in scm_threads_prehistory (base=base@entry=0x2deff0c)
	 at threads.c:2176
     #2  0x00404b89 in scm_i_init_guile (base=base@entry=0x2deff0c) at init.c:386
     #3  0x00402344 in scm_i_init_thread_for_guile (base=0x2deff0c,
	 parent=<optimized out>) at threads.c:835
     #4  scm_i_init_thread_for_guile (base=0x2deff0c, parent=<optimized out>)
	 at threads.c:814
     #5  0x00402519 in scm_init_guile () at threads.c:869
     #6  0x004013c0 in main () at guile-hello.c:13
     (gdb) p base->mem_base
     $1 = (void *) 0x0

In the former case, scm_i_with_guile_and_parent does this:

     static void *
     scm_i_with_guile_and_parent (void *(*func)(void *), void *data, SCM parent)
     {
       struct with_guile_args args;

       args.func = func;
       args.data = data;
       args.parent = parent;

       return GC_call_with_stack_base (with_guile_and_parent, &args);
     }        ^^^^^^^^^^^^^^^^^^^^^^^

and the call to GC_call_with_stack_base correctly initializes the
stack base:

     GC_API void * GC_CALL GC_call_with_stack_base(GC_stack_base_func fn, void *arg)
     {
	 struct GC_stack_base base;
	 void *result;

	 base.mem_base = (void *)&base; <<<<<<<<<<<<<<<<<<<<<<<<<<

I have verified in the debugger that base.mem_base gets a good value
here.

By contrast, in the test program, GC_call_with_stack_base is never
called.  Instead, GC_get_stack_base is called, which returns zero.
The reason for that seems to be that GC_get_stack_base is called
_before_ GC_init:

     (gdb) break GC_get_stack_base
     Breakpoint 1 at 0x4bbed8
     (gdb) break GC_init
     Breakpoint 2 at 0x4bbfa8
     (gdb) r
     Starting program: D:\usr\eli\utils\guile-2.0.9\guile-hello.exe
     [New Thread 11200.0x39ac]

     Breakpoint 1, 0x004bbed8 in GC_get_stack_base ()
     (gdb) bt
     #0  0x004bbed8 in GC_get_stack_base ()
     #1  0x00402508 in scm_init_guile () at threads.c:868
     #2  0x004013c0 in main () at guile-hello.c:13
     (gdb) c
     Continuing.

     Breakpoint 2, 0x004bbfa8 in GC_init ()
     (gdb) bt
     #0  0x004bbfa8 in GC_init ()
     #1  0x0043d53b in scm_storage_prehistory () at gc.c:653
     #2  0x00404b81 in scm_i_init_guile (base=base@entry=0x2deff0c) at init.c:385
     #3  0x00402344 in scm_i_init_thread_for_guile (base=0x2deff0c,
	 parent=<optimized out>) at threads.c:835
     #4  scm_i_init_thread_for_guile (base=0x2deff0c, parent=<optimized out>)
	 at threads.c:814
     #5  0x00402519 in scm_init_guile () at threads.c:869
     #6  0x004013c0 in main () at guile-hello.c:13
     (gdb)

(Stepping through GC_init shows that GC_setpagesize is called and
returns the correct value: 0x1000.  But it is called too late.)

This happens because scm_init_guile calls GC_get_stack_base without
verifying that libgc was initialized.

Changing the test program to call GC_init at the beginning, like this:

     #include <stdio.h>
     #include <guile/2.0/libguile.h>
     #include <gc/gc.h>

     int
     main (void)
     {
       GC_init ();
       scm_init_guile ();
       return 0;
     }

passes the stack overflow test, but crashes further down the Guile
initialization path:

     Program received signal SIGSEGV, Segmentation fault.
     0x0042c66d in symbol_lookup_assoc_fn (obj=0x2f5870, alist=0x1e4d50,
	 closure=0x0) at symbols.c:176
     176           SCM sym = SCM_CAAR (alist);
     (gdb) bt
     #0  0x0042c66d in symbol_lookup_assoc_fn (obj=0x2f5870, alist=0x1e4d50,
	 closure=0x0) at symbols.c:176
     #1  0x0046a045 in weak_bucket_assoc (table=table@entry=0x2d8fd8,
	 buckets=buckets@entry=0x2d4000, bucket_index=bucket_index@entry=2165,
	 hash_fn=hash_fn@entry=0x42c110 <symbol_lookup_hash_fn>,
	 assoc=assoc@entry=0x42c63c <symbol_lookup_assoc_fn>,
	 object=object@entry=0x2f5870, closure=closure@entry=0x0) at hashtab.c:214
     #2  0x0046a80e in scm_hash_fn_create_handle_x (table=0x2d8fd8, obj=0x2f5870,
	 init=init@entry=0x904,
	 hash_fn=hash_fn@entry=0x42c110 <symbol_lookup_hash_fn>,
	 assoc_fn=assoc_fn@entry=0x42c63c <symbol_lookup_assoc_fn>,
	 closure=closure@entry=0x0) at hashtab.c:698
     #3  0x0042c207 in intern_symbol (symbol=<optimized out>) at symbols.c:195
     #4  scm_i_str2symbol (str=0x4dd028 <scm_logbit_p__name_string_raw_cell>)
	 at symbols.c:218
     #5  0x0042c440 in scm_string_to_symbol (
	 string=string@entry=0x4dd028 <scm_logbit_p__name_string_raw_cell>)
	 at symbols.c:323
     #6  0x0041d0b5 in scm_init_numbers () at ../libguile/numbers.x:48
     #7  0x00404cb9 in scm_i_init_guile (base=base@entry=0x2deff0c) at init.c:453
     #8  0x00402348 in scm_i_init_thread_for_guile (base=0x2deff0c,
	 parent=<optimized out>) at threads.c:835
     #9  scm_i_init_thread_for_guile (base=0x2deff0c, parent=<optimized out>)
	 at threads.c:814
     #10 0x0040251d in scm_init_guile () at threads.c:869
     #11 0x004013c5 in main () at guile-hello.c:15
     (gdb)

Any further ideas?