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

From: Oleg Jurtšenko <oleg(at)fts(dot)ee>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Oleg Jurtšenko <oleg(dot)jurtsenko(at)fts(dot)ee>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5235: Segmentation fault under high load through JDBC
Date: 2010-01-14 20:22:53
Message-ID: 4B4F7D1D.2080301@fts.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

After upgrading to the latest patch level: PostgreSQL 8.4.2 on
i386-portbld-freebsd8.0
I have got a different core dump

(gdb) bt
#0 0x328b1068 in malloc () from /lib/libc.so.7
#1 0x082f1be9 in load_tzoffsets ()
#2 0x080aa5ef in btrescan ()
#3 0x082db80c in FunctionCall2 ()
#4 0x080a4c15 in index_rescan ()
#5 0x080a44a2 in index_getprocid ()
#6 0x080aa662 in btgetbitmap ()
#7 0x082db759 in FunctionCall3 ()
#8 0x080a4f03 in index_endscan ()
#9 0x080a4f84 in index_insert ()
#10 0x08193881 in ExecIndexRestrPos ()
#11 0x34f14af8 in ?? ()
#12 0x37715f40 in ?? ()
#13 0x00000002 in ?? ()
#14 0x37da5e58 in ?? ()
#15 0x37da51f8 in ?? ()
#16 0x37da51fc in ?? ()
#17 0x37da5200 in ?? ()
#18 0x00000000 in ?? ()
#19 0x00000000 in ?? ()
#20 0x00000100 in ?? ()
#21 0x355a5c88 in ?? ()
#22 0x00000002 in ?? ()
#23 0x00000000 in ?? ()
#24 0xbfa00608 in ?? ()
#25 0x0818382b in ExecInitNode ()

which gave me an idea to tune "max_stack_depth". I increased it four
times from 2MB to 8MB and tried to run my test query: "select
instr(ad_parent_tree(?,?),'|'||?||'|') AS isItsOwnChild from dual;"
Execution was successful without segfault, but it took 25 seconds to get
a result.

Regards, Oleg

Tom Lane wrote:
> Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
>
>> Still, even though the code is preposterous, the result shouldn't be a
>> segfault. I wasn't able to reproduce one myself (using 8.3.7 on
>> freebsd 7.2) however.
>>
>
> Yeah, for me it also recurses till the exception is hit, and then
> processes that successfully. This is effectively identical to a case
> in the standard regression tests, which also intentionally recurses
> till stack overflow. Since we have FreeBSD machines in the buildfarm,
> it is reasonably safe to conclude that this isn't a generic FreeBSD
> bug. I suspect the OP has used some unusual configure/build option
> or linked in some nonstandard code that is causing the available
> stack space to change unexpectedly.
>
> regards, tom lane
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tim Bunce 2010-01-14 20:45:06 Re: Termination When Switching between PL/Perl and PL/PerlU
Previous Message Justin Pitts 2010-01-14 19:03:45 Re: BUG #5269: postgres backend terminates with SIGSEGV