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

From Tom Lane
Subject Re: upper() problem in 7.0.2
Date
Msg-id 1826.962917401@sss.pgh.pa.us
Whole thread Raw
In response to upper() problem in 7.0.2  ("Christopher L. Cousins" <chris@impulse.net>)
Responses Re: upper() problem in 7.0.2  ("Christopher L. Cousins" <chris-pgsql-bugs@cobalt.impulse.net>)
Re: upper() problem in 7.0.2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
"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.

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

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

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Christopher L. Cousins"
Date:
Subject: Re: upper() problem in 7.0.2
Next
From: Tom Lane
Date:
Subject: Re: upper() problem in 7.0.2