[pgpool-general: 105] Re: PGPool 3.0.5 General protection fault

[Tatsuo Ishii]

>> Thanks for the report. It seems parse tree data was overwritten by
>> garbage.  Do you have self contained test case?
> 
> Unfortunately this is not something that I have been able to reproduce
> manually with a
> 100% strike rate. Re-running the same query in a loop will often see a few
> crashes per
> hour but this is as best as I have been able to manage.
> 
> Please find attached core dumps of the process along with the pgpool
> configuration (Separate email) .
> Passwords and addresses have been removed from the configuration.
> 
> In our live system, it would appear to occur in the order of once every 5
> minutes. Production
> utilises connection pools.

You have a segfault every 5 minutes? Too bad. Probably there's
something wrong with the extended query protocol(via JDBC) and
replication mode. Will look into...
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp

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