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.
