On Sun, 10 Apr 2005, Joćo Assad wrote:
This time I have strace and gdb logs. Im sending attached the last 1000 lines of the mupdate process strace, the last 1000 of the mupdate thread strace and the gdb trace I managed to extract from the core dump.
So, I assume it was thread 33, the only one not in int80, which crashed.
Thread 33 (process 15913):
#0 0x00534478 in strcmp () from /lib/tls/libc.so.6
No symbol table info available.
#1 0x08075b07 in auth_newstate (identifier=0x810de40 "cyrus") at auth_unix.c:24
8
newstate = (struct auth_state *) 0x3834f5d8
pwd = (struct passwd *) 0x5e7fb8
grp = (struct group *) 0x5e7f08
mem = (char **) 0x8122494
#2 0x0805f8d9 in mysasl_proxy_policy (conn=0x8d07230, context=0x0, requested_user=0x8d07b40 "cyrus", rlen=5,
if (!strcmp(*mem, identifier)) break; where *mem came from: while ((grp = getgrent())) { for (mem = grp->gr_mem; *mem; mem++) {
Of course in another thread I see:
#12 0x0059ac31 in __nss_getent () from /lib/tls/libc.so.6
No symbol table info available.
#13 0x00551f51 in getgrent () from /lib/tls/libc.so.6
No symbol table info available.
#14 0x08075ad6 in auth_newstate (identifier=0x810de40 "cyrus") at auth_unix.c:24
6
newstate = (struct auth_state *) 0x383bd950
Which screams that we walked on some data in a non-reentrant interface.
I need to think about the right way to fix it.