Sergei Golovan writes:
> On 1/25/07, Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> > Definitely smells like a toolchain bug to me. In this case, since you've
> > enabled threads, erts_mtx_t is a properly declared struct type containing
> > among other things a pthread_mutex_t, an int, and a couple of pointers.
> > I don't remember how strict M68K is about alignment, but presumably it
> > wants
> > non-arbitrary alignment for word-sized fields, especially perhaps if
> > they're
> > used for atomic accesses.
> >
> > The error could be in gcc, gas, ld, or even libc.
> >
> > As GDB session on the core dump should tell us more about the location
> > of the crash, the failing instruction, and what data it tried to access.
>
> Here are two backtraces, without and with DEBUG defined. If you need
> some additional info, I'll try to give it also
...
> With debug.
> -----------------------------------------------------
> (gdb) bt
> #0 0xc0103522 in kill () from /lib/libc.so.6
> #1 0xc004a87e in pthread_kill () from /lib/libpthread.so.0
> #2 0xc004a8b6 in raise () from /lib/libpthread.so.0
> #3 0xc0103380 in raise () from /lib/libc.so.6
> #4 0xc0104266 in abort () from /lib/libc.so.6
> #5 0x8009b534 in et_abort (expr=0x800fb643 "_is_aligned(x)",
> file=0x800fa37f "beam/erl_lock_check.c", line=1018) at
> beam/erl_term.c:45
> #6 0x8009c1b4 in checked_make_boxed (x=0x0, file=0x800fa37f
> "beam/erl_lock_check.c", line=1018) at beam/erl_term.c:123
> #7 0x80092bca in erts_lc_init_lock (lck=0x8015abe2, name=0x800f0178
> "binary_alloc", flags=0) at beam/erl_lock_check.c:1018
> #8 0x800504c0 in erts_mtx_init (mtx=0x8015abba, name=0x800f0178
> "binary_alloc") at beam/erl_threads.h:249
> #9 0x800731e6 in erts_init_binary () at beam/binary.c:40
> #10 0x8002d85c in erl_init () at beam/erl_init.c:211
> #11 0x8002e568 in erl_start (argc=37, argv=0xeffff58c) at beam/erl_init.c:907
> #12 0x8001a6fe in main (argc=37, argv=0xeffff584) at sys/unix/erl_main.c:28
> -----------------------------------------------------
What's happening is that an embedded Eterm field in the mutex,
placed there and used by the lock checker, isn't word-aligned,
which triggers an abort() in make_boxed(). In your non-debug
GDB trace this error went unnoticed but later on _seriously_
broke the GC.
The problem is still one of alignment. It seems that your M68K
toolchain doesn't align
struct { int x; } var;
to a 32-bit boundary. Whether that is the bug, or whether the
lock checker's alignment-of-static-data assumption is the bug,
I cannot tell until someone sends me a pointer to the M68K Linux
(or SVR4) ABI document.
/Mikael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
