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  (Craig Ringer <craig@postnewspapers.com.au>)
Re: BUG #5235: Segmentation fault under high load through JDBC  (Oleg Jurtšenko <oleg.jurtsenko@fts.ee>)
Список 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 по дате отправления:

Предыдущее
От: Kris Jurka
Дата:
Сообщение: Re: BUG #5099: When MetaData is acquired, it becomes an SQL error.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: BUG #5210: error in intidb process when installing on japanese