Re: BUG #5235: Segmentation fault under high load through JDBC
От | Tom Lane |
---|---|
Тема | Re: BUG #5235: Segmentation fault under high load through JDBC |
Дата | |
Msg-id | 27295.1260230948@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #5235: Segmentation fault under high load through JDBC ("Oleg Yurchenko" <oleg@fts.ee>) |
Ответы |
Re: BUG #5235: Segmentation fault under high load through
JDBC
Re: BUG #5235: Segmentation fault under high load through JDBC |
Список | pgsql-bugs |
"Oleg Yurchenko" <oleg@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
В списке pgsql-bugs по дате отправления: