Skip site navigation (1) Skip section navigation (2)

Re: BUG #5235: Segmentation fault under high load through JDBC

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Oleg Yurchenko" <oleg(at)fts(dot)ee>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5235: Segmentation fault under high load through JDBC
Date: 2009-12-08 00:09:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
"Oleg Yurchenko" <oleg(at)fts(dot)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

In response to


pgsql-bugs by date

Next:From: Robert HaasDate: 2009-12-08 04:10:01
Subject: Re: BUG #5210: error in intidb process when installing on japanese
Previous:From: Kris JurkaDate: 2009-12-07 22:50:56
Subject: Re: BUG #5099: When MetaData is acquired, it becomes an SQL error.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group