Re: Fwd: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf

Hi!

On 2004-06-08 11:18 -0400, Tom Lane wrote:
> Can you try again to get a debugger stack trace? Maybe with the patch
> there'll be a more sensible stack...

I am now able to reproduce this bug. I installed package 'winbind' and
changed the hosts line in /etc/nsswitch.conf to

hosts: wins files dns

(i. e. prepended wins). I recompiled postgresql with debugging and
without stripping and tried to get a stack trace. Something really
seems to mess up the stack, but running postmaster under electric
fence seems to improve it (and it should also narrow down the error):

---------------- snip ---------------------
postgres(at)donald:/usr/lib/postgresql/bin$ gdb ./postmaster
GNU gdb 6.1-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) efence
Enabled Electric Fence
(gdb) set args -D /var/lib/postgres/data
(gdb) r
Starting program: /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
[Thread debugging using libthread_db enabled]
[New Thread 1078114272 (LWP 2961)]

Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
2004-06-08 19:27:43 [2961] LOG: konnte IPv6-Socket nicht erstellen: Die Adressfamilie wird von der Protokollfamilie nicht unterstützt

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1078114272 (LWP 2961)]
0x402e675e in getc () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0x402e675e in getc () from /lib/tls/i686/cmov/libc.so.6
#1 0x0814142d in next_token (fp=0xbfffde4c, buf=0xbfffde54 "", bufsz=1109025003) 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)
---------------- snip ---------------------

The bufsz parameter of next_token really seems to be corrupted, but
line 102 is

while ((c = getc(fp)) != EOF && (pg_isblank(c) || c == ',')) ;

so the function already crashes while skipping the whitespace and
bufsz does not yet come into real play yet (apart from determining
end_buf, which is not yet used up to this point).

I would like to debug this further (if you cannot reproduce this), but
I grepped the whole source tree for an invocation of
next_token[_expand] and found nothing. Where the heck this is called
from? Looking at the stacktrace it seems to be kind of a callback from
libnss_wins, but somewhere this must be set!?

So who calls next_token and who sets the file, buffer and bufsz
parameters? Can you make any sense of this?

Thanks for any idea!

Martin

--
Martin Pitt Debian GNU/Linux Developer
martin(at)piware(dot)de mpitt(at)debian(dot)org
http://www.piware.de http://www.debian.org