Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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!



Impulse Internet Services    /    \
____________________________/      \_____ <chris(at)impulse(dot)net>

In response to


pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group