[pgpool-general: 1199] Re: 3.2.1 segfaults at startup on Fedora17

Lonni J Friedman netllama at gmail.com
Wed Nov 28 00:42:02 JST 2012


On Tue, Nov 27, 2012 at 7:35 AM, Tatsuo Ishii <ishii at postgresql.org> wrote:
>> I can't tell whether the lack of response from the pgpool team means:
>> * we're being ignored
>> * newer versions aren't supported
>> * the issue is being investigated
>> * something else?
>
> Due to limited resource. We are busy for real world business and other
> issues (see the bug track).

Does this mean that you will never investigate this, or that its
merely prioritized behind higher priority bugs?

That's fine and understandable if you have higher priority issues that
are consuming the team's time, but since we're not mind readers, we
have no way of knowing this unless someone communicates it.  When
there is no reply, or a very delayed response to simply acknowledge
reported bugs, that decreases the incentive of users to expend the
effort to report bugs, and in the long run, use pgpool at all.


> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese: http://www.sraoss.co.jp
>
>> On Tue, Nov 20, 2012 at 11:17 AM, Lonni J Friedman <netllama at gmail.com> wrote:
>>> On Tue, Nov 20, 2012 at 11:03 AM,  <maniac at localhost.sk> wrote:
>>>> Hello,
>>>>
>>>> I have simmilar problem on Slacware64 v14 with glibc2.15 and gcc 4.7.1 .
>>>> Also have tried the latest GIT version of pgpool - the same result.
>>>>
>>>> Symptoms:
>>>> Once I enable watchdog and start it on one server it segfaults when it can't
>>>> find other pgpool watchdog on network already. Sometimes it eventually start and
>>>> then all is OK - pgpool on other server starts fine as watchdog on the other server
>>>> already can connect to watchdog on the first server.
>>>> Sometimes means X tries to run it, where X is purely random, usually on 5-30 try it starts and work fine then..
>>>> Of course I have to clean semaphores and shared memory via the ipcrm as
>>>> those never get unregistered after pgpool segfault crash..
>>>>
>>>> When I tried to compile pgpool on older system (Slackware64 v13.1.0) with
>>>> glibc2.11 and gcc 4.4.4 and copy the pgpool binary on Slackware64 v14 it
>>>> just works on the Slackware v14.
>>>>
>>>> Here is the backtrace of the binary compiled on Slackware64 v14:
>>>>
>>>> gsql at wwwpri:~$ /usr/local/bin/pgpool -f /usr/local/etc/pgpool.conf -n -D
>>>> 2012-11-20 19:57:12 LOG:   pid 10639: wd_chk_sticy: all commands have sticky bit
>>>> 2012-11-20 19:57:12 LOG:   pid 10639: watchdog might call network commands which using sticky bit.
>>>> 2012-11-20 19:57:12 LOG:   pid 10639: Backend status file /tmp/pgpool_status discarded
>>>> 2012-11-20 19:57:14 LOG:   pid 10639: wd_create_send_socket: connect() reports failure (Connection refused). You can safely ignore this while starting up.
>>>> Segmentation fault (core dumped)
>>>> pgsql at wwwpri:~$
>>>>
>>>> pgsql at wwwpri:~$ gdb /usr/local/bin/pgpool core
>>>> GNU gdb (GDB) 7.5
>>>> Copyright (C) 2012 Free Software Foundation, Inc.
>>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>>> This is free software: you are free to change and redistribute it.
>>>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>>>> and "show warranty" for details.
>>>> This GDB was configured as "x86_64-slackware-linux".
>>>> For bug reporting instructions, please see:
>>>> <http://www.gnu.org/software/gdb/bugs/>...
>>>> Reading symbols from /usr/local/bin/pgpool...done.
>>>> [New LWP 10639]
>>>>
>>>> warning: Could not load shared library symbols for linux-vdso.so.1.
>>>> Do you need "set solib-search-path" or "set sysroot"?
>>>> [Thread debugging using libthread_db enabled]
>>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>>> Core was generated by /usr/local/bin/pgpool -f /usr/local/etc/pgpool.conf -n -D'.
>>>> Program terminated with signal 11, Segmentation fault.
>>>> #0  0x00007fc0882db040 in pthread_detach () from /lib64/libpthread.so.0
>>>> (gdb) backtrace
>>>> #0  0x00007fc0882db040 in pthread_detach () from /lib64/libpthread.so.0
>>>> #1  0x0000000000478577 in wd_is_unused_ip (ip=<optimized out>) at wd_ping.c:159
>>>> #2  0x00000000004764fd in wd_init () at wd_init.c:91
>>>> #3  0x0000000000475817 in wd_main (fork_wait_time=1) at watchdog.c:117
>>>> #4  0x000000000040634f in main (argc=<optimized out>, argv=<optimized out>) at main.c:642
>>>> (gdb)
>>>>
>>>> When I disable watchdog in pgpool.conf then pgpool works OK, but I need virtual IP so I have to use watchdog..
>>>>
>>>> To me it seems that pgpool-ii 3.2.1 (or git version) is not compatible with latest system (either glibc/pthread or gcc).
>>>>
>>>> I can provide additional data if required, but unfortunately can't find the root cause by my own :(
>>>
>>>
>>> Yup, that sounds exactly like the same problem (and your backtrace
>>> looks similar to mine).  It would be nice if the pgpool team at least
>>> acknowledged the problem, even if they don't have a solution.



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
L. Friedman                                    netllama at gmail.com
LlamaLand                       https://netllama.linux-sxs.org


More information about the pgpool-general mailing list