Re: Fwd: Bug#249083: postgresql: Postgres SIGSEGV if wins in nsswitch.conf - Mailing list pgsql-bugs

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=20

  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@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 condition=
s.
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/d=
ata
[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 Ad=
ressfamilie wird von der Protokollfamilie nicht unterst=FCtzt

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=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)
---------------- snip ---------------------

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

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

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

--=20
Martin Pitt                 Debian GNU/Linux Developer
martin@piware.de                      mpitt@debian.org
http://www.piware.de             http://www.debian.org