Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

re: new BIND in 10.0_RC5/sparc dies w/Bus error



this appears to be a badly aligned structure issue.  i can reproduce
it by doing "anita interact" with any recent sparc .iso, editing the
named.conf to start, starting named, and doing 'dig ns netbsd.org'
would trigger the crash.

the stack trace is:

(gdb) bt
#0  ns__client_request (handle=0xeb02d008, eresult=ISC_R_SUCCESS, region=<optimized out>, arg=<optimized out>)
    at /usr/10/src/external/mpl/bind/lib/libns/../../dist/lib/ns/client.c:1825
#1  0xedb0dc80 in isc__nm_async_readcb (worker=0x0, ev0=0xeccf7ad4) at /usr/10/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/netmgr/netmgr.c:2914
#2  0xedb0dde0 in isc__nm_readcb (sock=0xecfe8808, uvreq=0xeb0b6008, eresult=ISC_R_SUCCESS)
    at /usr/10/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/netmgr/netmgr.c:2887
#3  0xedb1183c in udp_recv_cb (handle=<optimized out>, nrecv=53, buf=0xeccf7c54, addr=<optimized out>, flags=0)
    at /usr/10/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/netmgr/udp.c:653
#4  0xedb3aec8 in uv__udp_recvmsg (handle=0xecfe89f8) at /usr/10/src/external/mit/libuv/lib/../dist/src/unix/udp.c:303
#5  uv__udp_io (loop=<optimized out>, w=0xecfe8a38, revents=1) at /usr/10/src/external/mit/libuv/lib/../dist/src/unix/udp.c:178
#6  0xedb3a034 in uv__io_poll (loop=0xecf62810, timeout=<optimized out>) at /usr/10/src/external/mit/libuv/lib/../dist/src/unix/kqueue.c:390
#7  0xedb431a0 in uv_run (loop=0xecf62810, mode=UV_RUN_DEFAULT) at /usr/10/src/external/mit/libuv/lib/../dist/src/unix/core.c:406
#8  0xedb106ec in nm_thread (worker0=0xecf62808) at /usr/10/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/netmgr/netmgr.c:704
#9  0xedb20f44 in isc__trampoline_run (arg=0xecf36be0) at /usr/10/src/external/mpl/bind/lib/libisc/../../dist/lib/isc/trampoline.c:192
#10 0xed9ecda8 in pthread__create_tramp (cookie=0xecf7b000) at /usr/10/src/lib/libpthread/pthread.c:595

and the problem is that in ns__client_request(), we end up with:

(gdb) p client
$17 = (ns_client_t *) 0xeb02d144

but the alignment requirement for this structure is 8-bytes as it has
64-bit members.  the fault actually occurs when reading two 4-byte
members in one instruction:

1825            env = client->manager->aclenv;
1826            if (client->sctx->blackholeacl != NULL &&
   0x00036e70 <+408>:     ldd  [ %l6 + 0x10 ], %g2

"sctx" and "manager" are at offsets 0x10 and 0x14 and can both be
read with a single ldd (64-bit load) but this requires correct
alignment.

i didn't track down how this client value is allocated, it's all
via some opaque handle thing in the libraries, but this is a bug
in the new bind not allocating structures properly aligned.


.mrg.


Home | Main Index | Thread Index | Old Index