Hi,

firstly -- thanks a lot for the efforts for straightening the matters.

I'm having a busy time right now, but I will try to apply your

solution ASAP, and so I need you to know how much I appreciate it!

> > 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.
>
> Hydra, a continuous integration system, runs Guile's "make check" with
> threads disabled on several POSIX platforms, so there's no need for
> Panicz to do this test.

Sorry, I disagree. "make check" is not the issue here: Guile passes
it on my machine with flying colors (see my reports back then). And
yet a simple program shown by Panicz aborts due to "stack overflow".
I was suggesting to configure Guile on GNU/Linux without threads and
run that same program: perhaps it will also fail.

So I eventually tried that (after having set up a virtual box especially

for that purpose), and everything went smoothly -- the "hello" message

was displayed without any complaints, despite the lack of threads.

In the meantime I've been still trying to build guile+bdw-gc with

thread support, and to spot the exact place which causes the error

message to pop out, but it's terribly slow (all the components of

libguile and guile.exe get rebuilt from scratch, in spite of the fact

that the error occurs at the guile-procedures.texi generation stage),

and I've been just placing some output messages here and there

throughout procedures in libgc/win32_threads.c (I wonder if there's

any way to configure the program, whether it be libgc or guile,

so that it would print the C backtrace when the popup appears)

Best regards,