[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: how does one debug a SEGV in scm_threads_prehistory?
From: |
Neil Jerram |
Subject: |
Re: how does one debug a SEGV in scm_threads_prehistory? |
Date: |
Thu, 19 Jun 2008 14:14:39 +0100 |
2008/6/18 Bruce Korb <address@hidden>:
> 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