Re: ERROR: invalid memory alloc request size 0

Hi Tom,

OK.  We recompiled with --enable-debug.
Here is a more detailed backtrace.

Thanks
John
------------------------------------------------
[root@interage jhagstrand]# gdb /usr/bin/postgres 21153
GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/tls/libthread_db.so.1".

Attaching to program: /usr/bin/postgres, process 21153
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libreadline.so.4...done.
Loaded symbols for /usr/lib/libreadline.so.4
Reading symbols from /lib/libtermcap.so.2...done.
Loaded symbols for /lib/libtermcap.so.2
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libm.so.6...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
0x00847c32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) b errfinish
Breakpoint 1 at 0x81a799d: file elog.c, line 319.
(gdb) cont
Continuing.

Breakpoint 1, errfinish (dummy=0) at elog.c:319
319             ErrorData  *edata = &errordata[errordata_stack_depth];
(gdb) bt
#0  errfinish (dummy=0) at elog.c:319
#1  0x081a85de in elog_finish (elevel=20,
    fmt=0x8231d80 "invalid memory alloc request size %lu") at elog.c:853
#2  0x081b3dd6 in MemoryContextAlloc (context=0x9f10598, size=0) at
mcxt.c:482
#3  0x0807411d in gistSplit (r=0xbe9a1938, buffer=805, itup=0x9f25128,
    len=0xbfec3eac, giststate=0xbfec4070, res=0xbfec402c) at gist.c:1348
#4  0x080725bb in gistlayerinsert (r=0xbe9a1938, blkno=143, itup=0xbfec3fe4,
    len=0xbfec3fe8, res=0xbfec402c, giststate=0xbfec4070) at gist.c:522
#5  0x080723be in gistlayerinsert (r=0xbe9a1938, blkno=188, itup=0xbfec3fe4,
    len=0xbfec3fe8, res=0xbfec402c, giststate=0xbfec4070) at gist.c:470
#6  0x080723be in gistlayerinsert (r=0xbe9a1938, blkno=0, itup=0xbfec3fe4,
    len=0xbfec3fe8, res=0xbfec402c, giststate=0xbfec4070) at gist.c:470
#7  0x080722e5 in gistdoinsert (r=0xbe9a1938, itup=0x9f225d8,
res=0xbfec402c,
    giststate=0xbfec4070) at gist.c:425
#8  0x080721dc in gistinsert (fcinfo=0x9ec6ea8) at gist.c:348
#9  0x081ab6c9 in OidFunctionCall6 (functionId=775, arg1=166489768,
    arg2=166489768, arg3=166489768, arg4=166489768, arg5=166489768,
    arg6=166489768) at fmgr.c:1345
#10 0x0807f789 in index_insert (indexRelation=0xbe9a1938, datums=0xbfec5730,
    nulls=0xbfec5710 " \003", heap_t_ctid=0x9f24d04,
heapRelation=0xbf5fa308,
    check_uniqueness=0 '\0') at indexam.c:226
#11 0x080f5cd3 in ExecInsertIndexTuples (slot=0x0, tupleid=0x9f24d04,
    estate=0x9f21540, is_vacuum=0 '\0') at execUtils.c:877
#12 0x080f0d21 in ExecUpdate (slot=0x9f217d0, tupleid=0xbfec5870,
    estate=0x9f21540) at execMain.c:1629
#13 0x080f06cc in ExecutePlan (estate=0x9f21540, planstate=0x9f217f0,
    operation=CMD_UPDATE, numberTuples=0, direction=166489768,
dest=0x9f12c88)
    at execMain.c:1211
#14 0x080efa8e in ExecutorRun (queryDesc=0x9f21138,
    direction=ForwardScanDirection, count=0) at execMain.c:249
#15 0x0815140a in ProcessQuery (parsetree=0x9ec6ea8, plan=0x9f21138,
    params=0x9ec6ea8, dest=0x9f10598, completionTag=0xbfec59e0 "")
    at pquery.c:139
#16 0x08151d44 in PortalRunMulti (portal=0x9f1ef98, dest=0x9f12c88,
    altdest=0x9f12c88, completionTag=0xbfec59e0 "") at pquery.c:846
#17 0x081517e0 in PortalRun (portal=0x9f1ef98, count=2147483647,
dest=0x9f12c88,
    altdest=0x9f12c88, completionTag=0xbfec59e0 "") at pquery.c:483
#18 0x0814ea67 in exec_simple_query (
    query_string=0x9f125c8 "update property set salestatus = '4' where
salestatus = '3'") at postgres.c:873
#19 0x081508a5 in PostgresMain (argc=4, argv=0x9ec7318,
    username=0x9ec72e8 "jhagstrand") at postgres.c:2868
#20 0x08130e36 in BackendFork (port=0x9ed5750) at postmaster.c:2558
#21 0x08130932 in BackendStartup (port=0x9ed5750) at postmaster.c:2201
#22 0x0812f257 in ServerLoop () at postmaster.c:1113
#23 0x0812ec36 in PostmasterMain (argc=5, argv=0x9ec6468) at
postmaster.c:891
#24 0x0810689e in main (argc=5, argv=0xbfec6a54) at main.c:214
(gdb) Quit
------------------------------------------------

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, April 09, 2004 8:03 AM
> To: John Hagstrand
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] ERROR: invalid memory alloc request size 0
>
>
> "John Hagstrand" <john.hagstrand@interageresearch.com> writes:
> > (gdb) bt
> > #0  0x081e6056 in errfinish ()
> > #1  0x081e6e66 in elog_finish ()
> > #2  0x081f5112 in MemoryContextAlloc ()
> > #3  0x080758d0 in gistinsert ()
> > #4  0x08073bac in gistinsert ()
> > #5  0x0807396c in gistinsert ()
> > #6  0x0807396c in gistinsert ()
> > #7  0x08073865 in gistinsert ()
> > #8  0x08073732 in gistinsert ()
> > #9  0x081ead7b in OidFunctionCall6 ()
> > #10 0x080831c5 in index_insert ()
>
> BTW, I took a quick look through gist.c and saw no smoking gun, in the
> form of an obvious candidate for doing palloc(0).  gistreadbuffer()
> could do it if called on an empty page, but it doesn't look like it
> would be.  So we need more data.
>
> The above trace is misleading since gistinsert() is not recursive.
> I think what's really going on is that the executable has been stripped
> of static-function names and gdb is just reporting the nearest global
> function name.  So we're somewhere in that nest of little static
> functions called by gistinsert(), but it's hard to be sure where.
>
> Could I pester you to recompile with --enable-debug so we can get a more
> useful backtrace?  I was originally hoping to duplicate the problem
> here, but I now suspect it's an odd corner case that will be hard to
> replicate.
>
>             regards, tom lane
>