Martin Pitt <[EMAIL PROTECTED]> 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 0x421310b
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:
Martin Pitt <[EMAIL PROTECTED]> writes:
> For your convenience I wrote these hex sequences into two files
> 'token1' and 'token2' and tar.gz'ed them.
Mph ... no obvious pattern here.
$ od -t x1 token1
000 98 6e 2 41 91 31 f8 40
010
$ od -t x1 token2
000 98 e3 ed 40 9
Hi Tom!
On 2004-06-08 1:24 -0400, Tom Lane wrote:
> I didn't expect the failure to go away, only the consequent core dump.
I also hoped that the missing string termination caused the segfault,
but obviously it didn't (it was only a read operation after all).
> We still need to learn why winbind
Martin Pitt <[EMAIL PROTECTED]> writes:
> The submitter of this bug eventually reported back (there was a
> problem with his email address) and tested the updated package (with
> your patch); unfortunately it seems that the patch did not improve the
> output very much :-( He wrote:
I didn't expect
Hi again!
On 2004-05-25 15:13 -0400, Tom Lane wrote:
> I said:
> > I would suggest adding more paranoia along these lines:
>
> Actually the correct patch is as per attached. Even without a core
> dump, the original code would not print the token that was really
> causing the problem :-(. Please
Hi Tom!
On 2004-05-25 15:13 -0400, Tom Lane wrote:
> Actually the correct patch is as per attached. Even without a core
> dump, the original code would not print the token that was really
> causing the problem :-(. Please apply this patch and then tell us
> what you see with winbind.
Thank you
I said:
> I would suggest adding more paranoia along these lines:
Actually the correct patch is as per attached. Even without a core
dump, the original code would not print the token that was really
causing the problem :-(. Please apply this patch and then tell us
what you see with winbind.
Martin Pitt <[EMAIL PROTECTED]> writes:
> 2004-05-14 14:50:14 [8725] LOG: authentication file token too long, skippi=
> ng: "=98.=ED=F1
> Segmentation fault
Looking at the only place this message is produced, in
src/backend/libpq/hba.c, it appears that we are printing a string buffer
that is not
