mupdate thread died with SIGSEGV

[Derrick J Brashear]

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.