Re: Seg Fault in backend after beginning to use xpath (PG 9.0, FreeBSD 8.1)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: alan bryan <alan(dot)bryan(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Seg Fault in backend after beginning to use xpath (PG 9.0, FreeBSD 8.1)
Date: 2011-05-03 05:39:46
Message-ID: 12115.1304401186@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

alan bryan <alan(dot)bryan(at)gmail(dot)com> writes:
> 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
> #2 0x0000000800d717e1 in xmlDictReference () from /usr/local/lib/libxml2.so.5
> #3 0x0000000800d74ba5 in xmlSAX2StartDocument ()
> from /usr/local/lib/libxml2.so.5
> #4 0x0000000800ccee5f in xmlParseDocument () from /usr/local/lib/libxml2.so.5
> #5 0x0000000800ccef85 in xmlDoRead () from /usr/local/lib/libxml2.so.5
> #6 0x000000000076b58d in xpath ()
> #7 0x00000000005880e4 in GetAttributeByNum ()
> #8 0x0000000000588e91 in GetAttributeByName ()
> #9 0x00000000005850a3 in ExecProject ()
> #10 0x000000000058c5e4 in ExecScan ()
> #11 0x0000000000584a2d in ExecProcNode ()
> #12 0x000000000059bfc8 in ExecLimit ()
> #13 0x00000000005848f5 in ExecProcNode ()
> #14 0x0000000000583049 in standard_ExecutorRun ()
> #15 0x000000000067630d in PostgresMain ()
> #16 0x0000000000677921 in PortalRun ()
> #17 0x0000000000672ea4 in pg_parse_and_rewrite ()
> #18 0x0000000000675354 in PostgresMain ()
> #19 0x0000000000626afb in ClosePostmasterPorts ()
> #20 0x0000000000627a8e in PostmasterMain ()
> #21 0x00000000005bbea7 in main ()
> (gdb)

> Ideas? Need more info?

Well, the first thing that you should consider is rebuilding both PG and
libxml with debug symbols enabled, so you can get a stack trace that's
worth the electrons it's written on. That one has enough laughers in
the PG part to make me not trust the libxml part too much. That would
also help you find out what SQL command is being executed, which'd
possibly lead to being able to create a reproducible test case.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Greg Smith 2011-05-03 06:11:15 Re: pervasiveness of surrogate (also called synthetic) keys
Previous Message Scott Ribe 2011-05-03 05:18:22 Re: pervasiveness of surrogate (also called synthetic) keys