[Pgpool-general] segfault in pgpool 2.2

[Tatsuo Ishii]

Simone,

Please try included patches. It seems this only happens when the
application mixes SQL command PREPARE and extended protocol.
The reason why pgpool-II 2.1 does not crash is just it's lucky.
--
Tatsuo Ishii
SRA OSS, Inc. Japan

> Thanks. I will look into this.
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> 
> > 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
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgpool-general
-------------- next part --------------
Index: pool_process_query.c
===================================================================
RCS file: /cvsroot/pgpool/pgpool-II/pool_process_query.c,v
retrieving revision 1.144
diff -c -r1.144 pool_process_query.c
*** pool_process_query.c	14 Mar 2009 03:39:50 -0000	1.144
--- pool_process_query.c	1 May 2009 00:28:56 -0000
***************
*** 2104,2109 ****
--- 2104,2122 ----
  	if (node == NULL)
  		return 0;
  
+ 	/*
+ 	 * 2009/5/1 Tatsuo says: This test is not bogus. As of 2.2, pgpool
+ 	 * sets Portal->sql_string to NULL for SQL command PREPARE.
+ 	 * Usually this is ok, since in most cases SQL command EXECUTE
+ 	 * follows anyway. Problem is, some applications mix PREPARE with
+ 	 * extended protocol command "EXECUTE" and so on. Execute() seems
+ 	 * to think this never happens but it is not real. Someday we
+ 	 * should extract actual query string from PrepareStmt->query and
+ 	 * set it to Portal->sql_string.
+ 	 */
+ 	if (sql == NULL)
+ 		return 0;
+ 
  	if (pool_config->ignore_leading_white_space)
  	{
  		/* ignore leading white spaces */