I wrote:
> 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).
Turns
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"... , p=0x1bdbe0,
> > charlen=12) at like.c:53
> > #3 0xdab1d in textlike (s=0x1eeff0, p=0x1bdbe0) at like.c:10
On Thu, Jul 06, 2000 at 03:18:59AM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> > What I can do is create a fake dataset, find some values that cause the problem,
>then give
> > that to you. Would that be acceptable?
>
> Sure, if you can do that. I just want
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
>> 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
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> #2 0xdaa41 in fixedlen_like (
> s=0x1eeff4 "MQZSVRSJDSFR"... , 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
On Thu, Jul 06, 2000 at 03:18:59AM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> > What I can do is create a fake dataset, find some values that cause the problem,
>then give
> > that to you. Would that be acceptable?
>
> Sure, if you can do that. I just want
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> What I can do is create a fake dataset, find some values that cause the problem,
>then give
> that to you. Would that be acceptable?
Sure, if you can do that. I just want to reproduce the crash here.
regards, tom l
On Thu, Jul 06, 2000 at 03:10:28AM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> >> I don't think I believe that backtrace. Could you send me the dump
> >> file?
>
> > The core file is never written to disk (I did verify that the environment I am
>running
> > p
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
>> I don't think I believe that backtrace. Could you send me the dump
>> file?
> The core file is never written to disk (I did verify that the environment I am
>running
> postgres under was setup to allow core files).
I don't want the corefi
On Thu, Jul 06, 2000 at 12:48:53AM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> > I have been able to make the backend crash using psql. I also took a dump
> > of the database while I had some known values that would trigger the problem.
> > Because of this, I c
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> I have been able to make the backend crash using psql. I also took a dump
> of the database while I had some known values that would trigger the problem.
> Because of this, I can now reload the dump (to a dummy database) at any time to
> repr
On Wed, Jul 05, 2000 at 12:03:46PM -0400, Tom Lane wrote:
> "Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> > Using PHP4 or PHP3, the following query will ~sometimes~ cause the
> > backend to terminate. It depends the value of $searchstr and appears
> > (to me anyway) to be random. A $sea
"Christopher L. Cousins" <[EMAIL PROTECTED]> writes:
> Using PHP4 or PHP3, the following query will ~sometimes~ cause the
> backend to terminate. It depends the value of $searchstr and appears
> (to me anyway) to be random. A $searchstr that causes the backend to
> crash right now may work just
Your name : Christopher L. Cousins
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : AMD K7 (Athlon) ("AuthenticAMD"
686-class) 705 MHz
Operating System (example: Linux 2.0.26 ELF) : OpenBSD
14 matches
Mail list logo
