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

James Elsdon jamesys at gmail.com
Wed Dec 21 10:35:46 JST 2011


Hi Tatsuo


> 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.

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/20111221/04763406/attachment.html>


More information about the pgpool-general mailing list