Re: MemoryContextAlloc: invalid request size 1934906735 - Mailing list pgsql-hackers

On August 28, 2002 12:48 pm, D'Arcy J.M. Cain wrote:
> 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

Nope.  Tried adding "size += 64;" into MemoryContextAlloc() and it made no 
difference.  

I had also tried changing palloc.h and mcxt.c to turn MemoryContextAlloc() 
into a macro that called a modified version of the real one to try to narrow 
down where it was being called from but that wouldn't even run.  Is there 
another file I have to modify as well if I try that?  Here are the changes I 
tried.  See any reason that it shouldn't have worked if I rebuilt everything?

*** postgresql-server/work.i386/postgresql-7.2.2/src/backend/utils/mmgr/mcxt.c
Wed Aug 28 14:01:31 2002
--- mcxt.c  Mon Aug 26 21:51:31 2002
***************
*** 409,416 ****  * nodes/memnodes.h into postgres.h which seems a bad idea.  */ void *
! MemoryContextAlloc(MemoryContext context, Size size) {   AssertArg(MemoryContextIsValid(context));
   if (!AllocSizeIsValid(size))
--- 409,417 ----  * nodes/memnodes.h into postgres.h which seems a bad idea.  */ void *
! _MemoryContextAlloc(MemoryContext context, Size size, const char *f, int l) {
+   elog(NOTICE, "_MemoryContextAlloc called from %s line %d", f, l);   AssertArg(MemoryContextIsValid(context));
   if (!AllocSizeIsValid(size))

*** postgresql-server/work.i386/postgresql-7.2.2/src/include/utils/palloc.h 
Mon
Nov  5 12:46:36 2001
--- palloc.h    Mon Aug 26 21:51:46 2002
***************
*** 45,51 **** /*  * Fundamental memory-allocation operations (more are in utils/memutils.h)  */
! extern void *MemoryContextAlloc(MemoryContext context, Size size);
 #define palloc(sz)    MemoryContextAlloc(CurrentMemoryContext, (sz))

--- 45,52 ---- /*  * Fundamental memory-allocation operations (more are in utils/memutils.h)  */
! extern void *_MemoryContextAlloc(MemoryContext context, Size size, const 
char
*s, int l);
! #define MemoryContextAlloc(context, size) _MemoryContextAlloc(context, 
size, __FILE__, __LINE__)
 #define palloc(sz)    MemoryContextAlloc(CurrentMemoryContext, (sz))


> 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@{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.