"Oleg Yurchenko" <o...@fts.ee> writes:
> Program terminated with signal 11, Segmentation fault.
> #0 0x0839380b in MemoryContextAllocZeroAligned (context=0x2d9eaf70,
> size=16) at mcxt.c:559
> 559 mcxt.c: No such file or directory.
> in mcxt.c
> [New Thread 28b01140 (LWP 100115)]
> #(gdb)bt
> #14185 0x081c1024 in ExecTargetList (targetlist=0x2b61a158,
> econtext=0x2b619330, values=0x2b61a0c8, isnull=0x2b61a0d8 "",
> itemIsDone=0x2b61a170, isDone=0xbfbfe4f0) at execQual.c:5007
> #14186 0x081c14cd in ExecProject (projInfo=0x2b61a0e8, isDone=0xbfbfe4f0) at
> execQual.c:5222
So where are the 14184 intermediate call levels?
If that's actually accurate and not a symptom of gdb being confused,
it's reasonable to guess that something went into infinite recursion
and the segfault occurred when it ran out of stack space. But there's
no evidence here to suggest what that was. Have you got any
potentially-recursive C or Perl or Python functions? Because the system
ought to notice when it's getting into recursion trouble with any
higher-level code.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
