Re: upper() problem in 7.0.2 - Mailing list pgsql-bugs

From Christopher L. Cousins
Subject Re: upper() problem in 7.0.2
Date
Msg-id 20000706150340.A9354@cobalt.impulse.net
Whole thread Raw
In response to Re: upper() problem in 7.0.2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, Jul 06, 2000 at 05:03:21PM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <chris-pgsql-bugs@cobalt.impulse.net> writes:
> > #2  0xdaa41 in fixedlen_like (
> >     s=0x1eeff4 "MQZSVRSJDSFR"... <Address 0x1ef000 out of bounds>, p=0x1bdbe0,
> >     charlen=12) at like.c:53
> > #3  0xdab1d in textlike (s=0x1eeff0, p=0x1bdbe0) at like.c:100
>
> Oooh, I see it ... nasty!  fixedlen_like is effectively assuming that
> it can access one byte beyond the end of the data string.  You've
> managed to set up a situation where one byte beyond falls off the
> end of the world (or the end of the backend's allocated memory, anyway).
>
> I was having no luck reproducing it here, probably because of different
> malloc behavior on my OS.  Thanks for going the extra mile to get that
> backtrace.

No problem, I'm just glad I was able to reproduce it on a box I could get a
clean backtrace from.

> This bug has probably been there all along, but it'd be pretty
> low-probability under most circumstances.

FYI, either postgres 6.3.2 did not have this problem or what I am doing did
not trigger it in 6.3.2 (I recently upgraded from 6.3.2 to 7.0.2).

> Will create a patch shortly.  Need to look to see what other places
> may be using the same bogus coding pattern...

Ok, thanks!

--

--Chris

                              ____
Impulse Internet Services    /    \
____________________________/      \_____

http://www.impulse.net <chris@impulse.net>

pgsql-bugs by date:

Previous
From: "Christopher L. Cousins"
Date:
Subject: Re: upper() problem in 7.0.2
Next
From: Matthew Altus
Date:
Subject: ps_status.h on FreeBSD 4.0 problems and fix