Re: how does one debug a SEGV in scm_threads_prehistory?

["Neil Jerram" <neiljerram@googlemail.com>]

2008/6/18 Bruce Korb <bkorb@gnu.org>:
> Our main development server was "upgraded" to 64 bits, but mostly
> still runs 32 bit software,
> so this is from a 32 bit build on a 64 bit platform.  Naturally, this
> all works on 32 on 32 and
> on 64 on 64.  But with 32 on 64, not so well:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7f482fe in scm_threads_prehistory () from /usr/lib/libguile.so.17
> (gdb) bt
> #0  0xb7f482fe in scm_threads_prehistory () from /usr/lib/libguile.so.17
> #1  0xb7f4834b in scm_i_thread_sleep_for_gc () from /usr/lib/libguile.so.17
> #2  0xb7f48375 in scm_i_thread_put_to_sleep () from /usr/lib/libguile.so.17
> #3  0xb7f2f3e4 in scm_i_string_writable_chars () from /usr/lib/libguile.so.17
> #4  0xb7f2f53d in scm_c_string_set_x () from /usr/lib/libguile.so.17
> #5  0xb7f23839 in scm_read_token () from /usr/lib/libguile.so.17
[...]

There's definitely something very odd here, because
scm_threads_prehistory() should only be called as part of Guile's
start of day (once-only) initialization.

You could focus on debugging why this happens, using GDB: set a
breakpoint on scm_threads_prehistory, then work out who calls it and
why.  I doubt that will reveal the underlying problem here, but it may
give you (us) a clue about it.

Regards,
       Neil