Martin Pitt <martin@piware.de> writes:
> (gdb) bt
> #0 0x402e675e in getc () from /lib/tls/i686/cmov/libc.so.6
> #1 0x0814142d in next_token (fp=3D0xbfffde4c, buf=3D0xbfffde54 "", bufsz=
> =3D1109025003) at hba.c:102
> #2 0x4217ecb5 in str_list_make () from /lib/libnss_wins.so.2
> #3 0x421310bc in dyn_CACHEDIR () from /lib/libnss_wins.so.2
> #4 0x42139591 in lp_load () from /lib/libnss_wins.so.2
> #5 0xbfffe6f4 in ?? ()
> #6 0x00000400 in ?? ()
> #7 0x421c3020 in ?? () from /lib/libnss_wins.so.2
> #8 0x000003ff in ?? ()
> #9 0x00000000 in ?? ()
> #10 0x0000b000 in ?? ()
> #11 0x403553d9 in mprotect () from /lib/tls/i686/cmov/libc.so.6
> #12 0x40019ecc in Page_DenyAccess () from /usr/lib/libefence.so.0.0
> Previous frame inner to this frame (corrupt stack?)
> (gdb)
> So who calls next_token and who sets the file, buffer and bufsz
> parameters? Can you make any sense of this?
Either gdb is lying to you completely (certainly possible if stack is
corrupt) or something in libnss_wins is taking a wild jump that happens
to end up in next_token.
The only suggestion I have is to try to identify where control is headed
before the stack clobber occurs. Set breakpoints and see how far it
gets before crashing, narrow down the range, rinse and repeat. I'd
suggest starting in and around getaddrinfo() and getnameinfo(), since
that seems like the only area where winbind would introduce different
behavior.
regards, tom lane