On 16 Jun 2001, Manuel Sugawara wrote:
> [EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
>
> [...]
> > OK, this works with my system - no coredump, correct results. I'll
> > take a look at the glibc sources to verify that, but it looks like
> > this was fixed by [EMAIL PROTECTED] and included i
Manuel Sugawara <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Trond Eivind Glomsrød) writes:
>
> > Will do... what is the expected result of the testcase? It seems to
> > work alright for me, but I'm running a slightly newer version than we
> > have released yet... (glibc-2.2.3-11, look in ra
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
> Will do... what is the expected result of the testcase?
Given a sufficiently large discrepancy between the string lengths,
a core dump is the likely result. Try increasing the "16k" numbers
if it doesn't crash for you.
Good
Manuel Sugawara <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Manuel Sugawara <[EMAIL PROTECTED]> writes:
> > > [ vacuum analyze dies ]
> > > It is running on Redhat Linux 7.1 i686 with 2.4.2-2 kernel.
> > > Here is the back trace from gdb
> >
> > > (gdb) bt
> > > #0
Tom Lane <[EMAIL PROTECTED]> writes:
> Manuel Sugawara <[EMAIL PROTECTED]> writes:
> > [ vacuum analyze dies ]
> > It is running on Redhat Linux 7.1 i686 with 2.4.2-2 kernel.
> > Here is the back trace from gdb
>
> > (gdb) bt
> > #0 strcoll () at strcoll.c:229
>
> We've heard reports before of
Manuel Sugawara <[EMAIL PROTECTED]> writes:
> [ vacuum analyze dies ]
> It is running on Redhat Linux 7.1 i686 with 2.4.2-2 kernel.
> Here is the back trace from gdb
> (gdb) bt
> #0 strcoll () at strcoll.c:229
We've heard reports before of strcoll() crashing on apparently valid
input. It seems