From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Matt Magoffin" <postgresql(dot)org(at)msqr(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Many 8.3 server crashes in xmlCleanupCharEncodingHandlers() |
Date: | 2007-12-18 05:51:38 |
Message-ID: | 21750.1197957098@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Matt Magoffin" <postgresql(dot)org(at)msqr(dot)us> writes:
> Do you still happen to have that
> database dump I provided to you previously?
Not sure --- when are you thinking of, and what was the context?
I don't usually keep sample data unless the issue still seems open.
> I also noticed these in my log file, don't know if this is helpful:
> TRAP: FailedAssertion("!(pointer == (void *) (((long) ((pointer)) + ((4) -
> 1)) & ~((long) ((4) - 1))))", File: "mcxt.c", Line: 581)
> LOG: server process (PID 714) was terminated by signal 6: Abort trap
> TRAP: BadArgument("!(((header->context) != ((void *)0) &&
> (((((Node*)((header->context)))->type) == T_AllocSetContext))))", File:
> "mcxt.c", Line: 589)
> LOG: server process (PID 633) was terminated by signal 6: Abort trap
These are consistent with the idea that we've got a memory-allocation
problem, ie, libxml is trying to access data that was already freed.
But exactly where and how is not any more clear than before.
FWIW, I think it's unlikely that a single query will reproduce this,
because the problem looks to be an expectation that leftover data is
still valid when it ain't. What you need to be looking for is a series
of two or more queries that crash PG. Possibly it'll be easier to
reproduce with that in mind ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Magoffin | 2007-12-18 06:30:22 | Re: Many 8.3 server crashes in xmlCleanupCharEncodingHandlers() |
Previous Message | Matt Magoffin | 2007-12-18 04:50:59 | Re: Many 8.3 server crashes in xmlCleanupCharEncodingHandlers() |