Re: BUG #5235: Segmentation fault under high load through JDBC
От | Oleg Jurtšenko |
---|---|
Тема | Re: BUG #5235: Segmentation fault under high load through JDBC |
Дата | |
Msg-id | 4B1E9BF8.10904@fts.ee обсуждение исходный текст |
Ответ на | Re: BUG #5235: Segmentation fault under high load through JDBC (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #5235: Segmentation fault under high load through JDBC
|
Список | pgsql-bugs |
This the end of core dump. It is 8.3M bzip-ed. I can provide it on the request. I'm trying to compile Openbravo ERP application. There is no C/Perl/Python functions. My investigations show that pgsql catches segmentation fault on some| ||ported Oracle PLSQL function|: Query in the source code is following: select instr(ad_parent_tree(?,?),'|'||?||'|') AS isItsOwnChild from dual; Best regards, Oleg. Tom Lane wrote: > "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 по дате отправления: