Re: Many 8.3 server crashes in xmlCleanupCharEncodingHandlers()
От | Tom Lane |
---|---|
Тема | Re: Many 8.3 server crashes in xmlCleanupCharEncodingHandlers() |
Дата | |
Msg-id | 21750.1197957098@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Many 8.3 server crashes in xmlCleanupCharEncodingHandlers() ("Matt Magoffin" <postgresql.org@msqr.us>) |
Ответы |
Re: Many 8.3 server crashes in
xmlCleanupCharEncodingHandlers()
|
Список | pgsql-general |
"Matt Magoffin" <postgresql.org@msqr.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
В списке pgsql-general по дате отправления: