<div class="gmail_quote">Hi <span><font color="#888888">Tatsuo</font></span><div class="im"><br><br>> Thanks for the report. It seems parse tree data was overwritten by<br>
> garbage.  Do you have self contained test case?<br><br></div>Unfortunately this is not something that I have been able to reproduce manually with a <br>
100% strike rate. Re-running the same query in a loop will often see a few crashes per<br>
hour but this is as best as I have been able to manage.<br><br>Please find attached core dumps of the process along with the pgpool configuration (Separate email) .<br>Passwords and addresses have been removed from the configuration.<br>

<br>
In our live system, it would appear to occur in the order of once every 5 minutes. Production<br>utilises connection pools.<br><br>Regards,<span class="HOEnZb"><font color="#888888"><br>James Elsdon</font></span><div class="HOEnZb">

<div class="h5"><br><br><div class="gmail_quote"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>> Hello,<br>
> Firstly thanks for pgpool.<br>
<br>
</div>You are welcome!<br>
<div><div><br>
> PGPool (confirmed in 3.0.3 and 3.0.5, did not use 3.0.4) will produce the<br>
> following behaviour<br>
><br>
> pgpool[22132] general protection rip:41668d rsp:7fffb04a0d90 error:0<br>
><br>
><br>
> Core dump details below:<br>
><br>
> #0  0x000000000041668d in is_sequence_query (node=0x5ff438) at<br>
> pool_process_query.c:1528<br>
> #1  0x00000000004442fe in pool_where_to_send (query_context=0x602a70,<br>
>     query=0x5fddb8 "SELECT aaaaaaa, pppppppp, cccc, rrrrrrr, aaaaaa,<br>
> cccccccc, fffffffff, sssssss, ddd, gggggg, ppppp, mmmmmm FROM aaaaaaa_ccccc<br>
> WHERE aaaaaaa=$1", node=0x5ff438) at pool_query_context.c:447<br>
> 447                     if (is_select_query(node, query) &&<br>
> !is_sequence_query(node))<br>
> #2  0x0000000000440b15 in Parse (frontend=0x5f3070, backend=0x5f2040,<br>
> len=149, contents=0x610210 "") at pool_proto_modules.c:702<br>
> 702                     pool_where_to_send(query_context,<br>
> query_context->original_query,<br>
> #3  0x0000000000441d50 in ProcessFrontendResponse (frontend=0x5f3070,<br>
> backend=0x5f2040) at pool_proto_modules.c:2007<br>
> 2007                            status = Parse(frontend, backend, len,<br>
> contents);<br>
> #4  0x00000000004163eb in pool_process_query (frontend=0x5f3070,<br>
> backend=0x5f2040, reset_request=0) at pool_process_query.c:344<br>
> 344                                             status =<br>
> ProcessFrontendResponse(frontend, backend);<br>
> #5  0x00000000004094c2 in do_child (unix_fd=4, inet_fd=5) at child.c:328<br>
> 328                             status = pool_process_query(frontend,<br>
> backend, 0);<br>
> #6  0x0000000000403f75 in fork_a_child (unix_fd=4, inet_fd=5, id=30) at<br>
> main.c:1033<br>
> 1033                    do_child(unix_fd, inet_fd);<br>
> #7  0x00000000004068f5 in main (argc=<value optimized out>, argv=<value<br>
> optimized out>) at main.c:517<br>
> 517                     process_info[i].pid = fork_a_child(unix_fd,<br>
> inet_fd, i);<br>
><br>
> Core was generated by `pgpool: sss sss 10.10.10.11(3766'.<br>
> Program terminated with signal 11, Segmentation fault.<br>
> #0  0x000000000041668d in is_sequence_query (node=0x5ff438) at<br>
> pool_process_query.c:1528<br>
> 1528                    if (IsA(lfirst(lc), ResTarget))<br>
><br>
> (gdb) print lc->data.ptr_value<br>
> $5 = (void *) 0x73202c656d616e74<br>
> (gdb) print (int)lc->data.ptr_value<br>
> $6 = 1835101812<br>
> (gdb) print (ResTarget)lc->data.ptr_value<br>
> $7 = {type = 1835101812, name = 0x202c656d616e7275 <Address<br>
> 0x202c656d616e7275 out of bounds>, indirection = 0x6e6567202c626f64, val =<br>
> 0x6f6870202c726564, location = 539780462}<br>
><br>
> Host Details:<br>
><br>
> Linux PGPOOL01 2.6.16.60-0.21-smp #1 SMP Tue May 6 12:41:02 UTC 2008 x86_64<br>
> x86_64 x86_64 GNU/Linux<br>
><br>
>> gcc -v<br>
> Using built-in specs.<br>
> Target: x86_64-suse-linux<br>
> Configured with: ../configure --enable-threads=posix --prefix=/usr<br>
> --with-local-prefix=/usr/local --infodir=/usr/share/info<br>
> --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64<br>
> --enable-langux<br>
> Thread model: posix<br>
> gcc version 4.1.2 20070115 (SUSE Linux)<br>
<br>
</div></div>Thanks for the report. It seems parse tree data was overwritten by<br>
garbage.  Do you have self contained test case?<br>
<span><font color="#888888">--<br>
Tatsuo Ishii<br>
SRA OSS, Inc. Japan<br>
English: <a href="http://www.sraoss.co.jp/index_en.php" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
Japanese: <a href="http://www.sraoss.co.jp" target="_blank">http://www.sraoss.co.jp</a><br>
</font></span></blockquote></div><br>
</div></div></div><br>