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>
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 |