[Pgpool-general] segfault in pgpool 2.2

[Simone Tregnago]

Tatsuo Ishii wrote:
>> I've run it with gdb, as you wrote. But, as before, pgpool continues to
>> run and the segfault appears in the syslog, so I cannot run bt.
> 
> pgpool forks multiple child worker processes and you need to attach to
> one of the children. Problem is, the process which you play with is
> not known until you connect to pgpool. There are several ways to solve
> the problem:
> 
> 1) take core dump. you do: ulimit -c unlimited or something like this
>    and get segfault. You should get a coredump then see the stack
>    trace.
> 
> 2) set num_init_children to 1 then you can know which child process
>    you need to attach.
> 
> Please try one of them.
> 
> Or you could provide us self contained test case.

as I said before I cannot build a test case because the software is a
closed source ERP.
But, following your tips, I've reduced the processes by setting up only
one children, so now I'm able to attach to the right process and easily
trap the fault.

This is the fault:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb79746d0 (LWP 19428)]
0x080607d8 in is_select_query (node=0x83e95e4, sql=0x0)
     at pool_process_query.c:2110
2110			while (*sql && isspace(*sql))
--

It seems that the sql pointer parameter is null, so the while crashes
trying to use it with *sql.

The full stack trace is:
--
#0  0x080607d8 in is_select_query (node=0x83e95e4, sql=0x0)
     at pool_process_query.c:2110
#1  0x08060780 in load_balance_enabled (backend=0x83df738, node=0x83e95e4,
     sql=0x0) at pool_process_query.c:2081
#2  0x0808cc9c in Execute (frontend=0x83dff78, backend=0x83df738)
     at pool_proto_modules.c:703
#3  0x08090107 in ProcessFrontendResponse (frontend=0x83dff78,
     backend=0x83df738) at pool_proto_modules.c:1474
#4  0x0805a1bb in pool_process_query (frontend=0x83dff78, 
backend=0x83df738,
     connection_reuse=0, first_ready_for_query_received=0)
     at pool_process_query.c:321
#5  0x0804f0dc in do_child (unix_fd=3, inet_fd=4) at child.c:425
#6  0x0804be9d in fork_a_child (unix_fd=3, inet_fd=4, id=0) at main.c:828
#7  0x0804aef0 in main (argc=2, argv=0xbffdb5f4) at main.c:434
--

Going back seems that portal->sql_string is null.

Remind that with pgpool 2.1 all works well: I'm using it in
production. So it must be related with a difference between the two
versions.
Thanks
-- 
Simone Tregnago