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
>
