On Thu, Jul 06, 2000 at 05:03:21PM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
