Re: Many 8.3 server crashes in xmlCleanupCharEncodingHandlers()
От | Matt Magoffin |
---|---|
Тема | Re: Many 8.3 server crashes in xmlCleanupCharEncodingHandlers() |
Дата | |
Msg-id | 50373.192.168.1.108.1197959422.squirrel@msqr.us обсуждение исходный текст |
Ответ на | Re: Many 8.3 server crashes in xmlCleanupCharEncodingHandlers() (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
> 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 was referring to a dump I provided a link to you called "pg83-leads-sanitized.db" which was around 20 Dec, with email subject "Re: [GENERAL] 8.3b2 XPath-based function index server crash". >> 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 ... Thanks for the tips. I am trying to get some sort of reproducible series of queries, but so far no luck. I'll let you know if I find anything. -- m@
В списке pgsql-general по дате отправления: