On 03/05/2011 07:12, alan bryan wrote:
Our developers started to use some xpath features and upon deployment
we now have an issue where PostgreSQL is seg faulting periodically.
Any ideas on what to look at next would be much appreciated.
FreeBSD 8.1
PostgreSQL 9.0.3 (also tried upgrading to 9.0.4) built from ports
Libxml2 2.7.6 (also tried upgrading to 2.7.8) built from ports
pgsql logs show:
May 1 17:51:13 192.168.20.100 postgres[11862]: [94-1] LOG: server
process (PID 62112) was terminated by signal 11: Segmentation fault
syslog shows:
May 2 20:29:16 db3 kernel: pid 49956 (postgres), uid 70: exited on
signal 11 (core dumped)
May 2 21:06:37 db3 kernel: pid 39086 (postgres), uid 70: exited on
signal 10 (core dumped)
Checking out postgres.core and we see:
(gdb) bt
#0 0x00000008f5f19afd in pthread_mutex_lock () from /lib/libthr.so.3
#1 0x0000000800d22965 in xmlRMutexLock () from /usr/local/lib/libxml2.so.5
This is unusual. There isn't any need to use pthreads here. As far as I
can see, the normal build of libxml2 doesn't import it explicitly:
ldd /usr/local/lib/libxml2.so
/usr/local/lib/libxml2.so:
libz.so.5 => /lib/libz.so.5 (0x800889000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800e50000)
libm.so.5 => /lib/libm.so.5 (0x80104b000)
libc.so.7 => /lib/libc.so.7 (0x800647000)
Judging by the mix of SIGBUS and SIGSEGV, I'd say it is likely this is
causing you problems.
To make sure, you may want to rebuild libxml2 with WITHOUT_THREADS
defined. You may also need to rebuild postgresql afterwards.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
