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 [email protected] http://pgfoundry.org/mailman/listinfo/pgpool-general
