Thread: ERROR: invalid memory alloc request size 0
Hello, I'm getting the following error when I try to update or insert into a table. This just started happening today. The table has been working fine up to now. The table has 27,000 rows and 24 columns. ERROR: invalid memory alloc request size 0 Why does this happen? And how can I work around it? Thanks John John Hagstrand Interage Research, Inc. 18733 State Line Road Antioch, IL 60002 847 838 5371 john.hagstrand@interageresearch.com Information Technology Consulting www.interageresearch.com
"John Hagstrand" <john.hagstrand@interageresearch.com> writes:
> I'm getting the following error when I try to update or insert into a table.
> This just started happening today. The table has been working fine up to
> now. The table has 27,000 rows and 24 columns.
> ERROR: invalid memory alloc request size 0
What PG version is this, and what exactly is the table schema (and how
did you change it recently)? And let's see an exact example of a
failing query. It'd be even nicer if you could get a stack trace from
the errfinish call.
The only recent bugs of this ilk that I can recall had to do with
operations on zero-column tables. Probably you've found some new
corner case, but there's not enough info here to guess what.
regards, tom lane
"John Hagstrand" <john.hagstrand@interageresearch.com> writes:
> How do I get a stack trace?
Assuming you're using a system that has gdb ---
Start psql in one terminal window. Determine the PID of the backend
process attached to it (ps and/or the pg_stat_activity view will help
you here). In another window, become the postgres user, and run gdb
to attach to the process:
gdb /path/to/postgres-executable PID-of-process
... gdb prints a bunch of junk and then prompts for a command ...
gdb>
At this point issue two commands:
b errfinish
cont
Now go back to the psql window and issue the troublesome command. gdb
should pop up reporting a breakpoint stop at errfinish (and your psql
session will be hung). In gdb issue a "bt" command to get a backtrace.
Copy and paste the output, send it along. Issue "quit" to gdb to get
out of it, or "cont" if you want to inspect more errors.
A typical example gdb session is attached. Note that you won't get this
detailed a trace unless you compiled with --enable-debug. However, if
you don't see any routine names at all (just numbers) then you've got an
executable that was "stripped" of all symbolic information. Such a
trace will be useless, unfortunately; you'd have to recompile at least
an unstripped binary to tell me anything.
regards, tom lane
$ gdb /home/postgres/testversion/bin/postgres 16088
Attaching to program: /home/postgres/testversion/bin/postgres, process 16088
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.
warning: Can't find file postmaster referenced in dld_list.
Reading symbols from /usr/lib/libc.1...done.
Reading symbols from /usr/local/lib/libz.sl...done.
Reading symbols from /usr/lib/libdld.1...done.
0xc0142dd8 in ?? () from /usr/lib/libc.1
(gdb) b errfinish
Breakpoint 1 at 0x2a194c: file elog.c, line 311.
(gdb) cont
Continuing.
Breakpoint 1, errfinish (dummy=0) at elog.c:311
311 int elevel = edata->elevel;
(gdb) bt
#0 errfinish (dummy=0) at elog.c:311
#1 0x24dc80 in int4div (fcinfo=0x0) at int.c:650
#2 0x18c83c in ExecMakeFunctionResult (fcache=0x400fcec0,
econtext=0x400fd050, isNull=0x7b03bcc0 "@\013\233\220", isDone=0x0)
at execQual.c:1050
#3 0x18cf58 in ExecEvalFunc (fcache=0x400fcec0, econtext=0x400fd050,
isNull=0x7b03bcc0 "@\013\233\220", isDone=0x0) at execQual.c:1431
#4 0x18e778 in ExecEvalExprSwitchContext (expression=0x400fcec0,
econtext=0x400fd050, isNull=0x7b03bcc0 "@\013\233\220", isDone=0x0)
at execQual.c:2520
#5 0x1e3bb8 in evaluate_expr (expr=0x400fcec0, result_type=23)
at clauses.c:2213
#6 0x1e33fc in evaluate_function (funcid=154, result_type=23,
args=0x400b9cf0, func_tuple=0xc0064b70) at clauses.c:1806
#7 0x1e3298 in simplify_function (funcid=154, result_type=23,
args=0x400b9cf0, allow_inline=1 '\001', active_fns=0x0) at clauses.c:1732
#8 0x1e282c in eval_const_expressions_mutator (node=0x400b9480,
active_fns=0x0) at clauses.c:1141
#9 0x1e4b8c in expression_tree_mutator (node=0x400b9bb0,
mutator=0x40011eca <DINFINITY+2954>, context=0x0) at clauses.c:2986
#10 0x1e300c in eval_const_expressions_mutator (node=0x400b9bb0,
active_fns=0x0) at clauses.c:1574
#11 0x1e4afc in expression_tree_mutator (node=0x400b9bd0,
---Type <return> to continue, or q <return> to quit---
mutator=0x40011eca <DINFINITY+2954>, context=0x0) at clauses.c:2973
#12 0x1e300c in eval_const_expressions_mutator (node=0x400b9bd0,
active_fns=0x0) at clauses.c:1574
#13 0x1e26f8 in eval_const_expressions (node=0x0) at clauses.c:1069
#14 0x1d92d0 in preprocess_expression (parse=0x400b9140, expr=0x0, kind=1)
at planner.c:401
#15 0x1d9070 in subquery_planner (parse=0x400b9140, tuple_fraction=0)
at planner.c:228
#16 0x1d8edc in planner (parse=0x400b9140, isCursor=0 '\000', cursorOptions=0)
at planner.c:119
#17 0x21fccc in pg_plan_query (querytree=0x400b9140) at postgres.c:651
#18 0x21fd6c in pg_plan_queries (querytrees=0x0, needSnapshot=0 '\000')
at postgres.c:718
#19 0x21ffb0 in exec_simple_query (query_string=0x400b8c80 "select 1/0;")
at postgres.c:876
#20 0x222d54 in PostgresMain (argc=4, argv=0x4000d888,
username=0x40050a00 "postgres") at postgres.c:2981
#21 0x1ee51c in BackendRun (port=0x4005cef0) at postmaster.c:2697
#22 0x1edcfc in BackendStartup (port=0x4005cef0) at postmaster.c:2330
#23 0x1ec470 in ServerLoop () at postmaster.c:1167
#24 0x1ebf18 in PostmasterMain (argc=3, argv=0x7b03ab10) at postmaster.c:928
#25 0x1ac358 in main (argc=3, argv=0x7b03ab10) at main.c:257
#26 0xc0065784 in ?? () from /usr/lib/libc.1
(gdb) quit
The program is running. Quit anyway (and detach it)? (y or n) y
Detaching from program: /home/postgres/testversion/bin/postgres, process 16088
$
Hello Tom, Thanks for your help. I ran a backtrace as you suggested. Following is the output of the gdb session. John --------------------------- [root@interage bin]# gdb /usr/bin/postgres 31699 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"... (no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1". Attaching to program: /usr/bin/postgres, process 31699 Reading symbols from /lib/libpam.so.0...(no debugging symbols found)...done. Loaded symbols for /lib/libpam.so.0 Reading symbols from /lib/libssl.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /usr/lib/libkrb5.so.3...(no debugging symbols found)... done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...(no debugging symbols found)... done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libreadline.so.4... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libreadline.so.4 Reading symbols from /lib/libtermcap.so.2...(no debugging symbols found)... done. Loaded symbols for /lib/libtermcap.so.2 Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libnsl.so.1 ---Type <return> to continue, or q <return> to quit--- Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /usr/lib/libgssapi_krb5.so.2... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libk5crypto.so.3... (no debugging symbols found)...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)... 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 0x81e6056 (gdb) cont Continuing. Breakpoint 1, 0x081e6056 in errfinish () (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 () #11 0x0810f1ea in ExecInsertIndexTuples () #12 0x081092e4 in ExecEndPlan () #13 0x08108aca in ExecEndPlan () #14 0x08107c38 in ExecutorRun () #15 0x0817e00d in ProcessQuery () #16 0x0817eaf7 in PortalRun () #17 0x0817e47f in PortalRun () #18 0x0817ad54 in pg_plan_queries () #19 0x0817d2c0 in PostgresMain () #20 0x08157345 in ClosePostmasterPorts () #21 0x08156d43 in ClosePostmasterPorts () #22 0x08155218 in PostmasterMain () ---Type <return> to continue, or q <return> to quit--- #23 0x081548a4 in PostmasterMain () #24 0x08124dc6 in main () (gdb) -----------------------------
"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 ()
Well, that makes it a GIST index bug ... since you hadn't mentioned the
existence of any indexes on this table, I feel I've been shorted some
critical info ;-). What exactly are you doing with GIST on this table?
regards, tom lane
Tom, There are two indexes on the table, defined like this. CREATE INDEX idx_geo_property ON property USING gist (geom) CREATE UNIQUE INDEX idx_property_acct_ln ON property USING btree (acct, ln) John > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Thursday, April 08, 2004 10:19 PM > 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 () > > Well, that makes it a GIST index bug ... since you hadn't mentioned the > existence of any indexes on this table, I feel I've been shorted some > critical info ;-). What exactly are you doing with GIST on this table? > > regards, tom lane >
"John Hagstrand" <john.hagstrand@interageresearch.com> writes:
> CREATE INDEX idx_geo_property ON property USING gist (geom)
This must be the culprit. I seem to have deleted your prior mail that
would tell me the datatype of the geom column :-( ... what was it again?
And which GIST operator class are you using here?
regards, tom lane