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

[Tatsuo Ishii]

> 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