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

[James Elsdon]

Hi Tatsuo,
Just an update: based on your comment:
> Probably there's something wrong with the extended query protocol (JDBC)

I have switched the JDBC from v3 to v2 (Passing protocolVersion=2 to it) as
this
will effectively disable extended query. Since doing so (It's been ~4 days)
pgpool
is yet to crash. Good news thus far.

If (when) a fix for the original issue is found, please do tell.


Thanks and Regards,
James Elsdon

On Wed, Dec 21, 2011 at 12:45 PM, Tatsuo Ishii <ishii at postgresql.org> wrote:

> >> 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
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20120124/2ffd2cf9/attachment.html>