From: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MemoryContextAlloc: invalid request size 1934906735 |
Date: | 2002-08-28 16:48:19 |
Message-ID: | 20020828164825.A7CE81BB4@druid.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On August 28, 2002 09:23 am, Tom Lane wrote:
> The behavior looks a lot like a memory clobber, so perhaps the key
> variable is some difference in malloc's allocation strategy, causing
> two items to be adjacent in NetBSD where they are not on the other
> platforms we've tried.
Hmm. I might try adding some buffer in MemoryContextAlloc() and see if that
changes anything. One thing that may be different is that NetBSD is 64 bit
clean. I don't think the other i386 systems are.
> I eyeballed the chkpass code and didn't see any sign of buffer overruns,
> but maybe it needs a harder look.
It's pretty simple. Not even indexing. In fact, I wondered if I should add
some just like my other type that does do indexing. That seemed to be the
only real difference between the two and the other works.
> Hm --- I guess another possible variable is behavior of the local
> crypt() function. Is NetBSD's crypt perhaps willing to return strings
> longer than 13 chars?
Well, the value that it stores is the correct 13 character DES string.
> Did you try CVS tip both with and without --enable-cassert? That turns
> on memory context checking which might alter the failure in interesting
> ways.
No difference. It seems that PostgreSQL is too good at catching the problem
before the assert macros see it.
--
D'Arcy J.M. Cain <darcy(at){druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 2002-08-28 18:07:34 | Re: MemoryContextAlloc: invalid request size 1934906735 |
Previous Message | Vivek Khera | 2002-08-28 15:28:21 | Re: LIMIT 1 FOR UPDATE or FOR UPDATE LIMIT 1? |