Re: upper() problem in 7.0.2

From: "Christopher L(dot) Cousins" <chris-pgsql-bugs(at)cobalt(dot)impulse(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: upper() problem in 7.0.2
Date: 2000-07-06 22:03:40
Message-ID: 20000706150340.A9354@cobalt.impulse.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Jul 06, 2000 at 05:03:21PM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <chris-pgsql-bugs(at)cobalt(dot)impulse(dot)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(at)impulse(dot)net>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2000-07-06 22:19:38 Re: upper() problem in 7.0.2
Previous Message Tom Lane 2000-07-06 21:03:21 Re: upper() problem in 7.0.2