Re: BUG #6233: pg_dump hangs with Access Violation C0000005
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #6233: pg_dump hangs with Access Violation C0000005 |
Дата | |
Msg-id | 1317784584-sup-6771@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: BUG #6233: pg_dump hangs with Access Violation C0000005 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #6233: pg_dump hangs with Access Violation C0000005
|
Список | pgsql-bugs |
Excerpts from Tom Lane's message of mar oct 04 22:04:29 -0300 2011: > "Pavel Holec" <holec@email.cz> writes: > > In the meantime I tried debug in msvc2005 (Win7/32) and > > free(funcsig); in pg_dump.c line 7510 cause > > _ASSERTE(_CrtIsValidHeapPointer(pUserData)); in dbgheap.c line 1252 > > * If this ASSERT fails, a bad pointer has been passed in. It may be > > * totally bogus, or it may have been allocated from another heap. > > * The pointer MUST come from the 'local' heap. > > > If I comment free(funcsig); and next one free(funcsig_tag); pg_dump works fine. > > Hmm. I can see how that would happen if you're using one of the Windows > environments wherein malloc's done inside libpq have to be free'd inside > libpq. (The PQExpBuffer support code is in libpq...) > > However, the flaw in that explanation is that it would basically mean > pg_dump doesn't work at all on Windows, at least not if you have any > user-defined functions, and probably some other cases too because there > seem to be multiple instances of the dubious coding. It's a bit hard to > believe that nobody's noticed that before. Isn't this the kind of thing that you have to enable explicitly? It's something like this, no? http://msdn.microsoft.com/en-us/library/ff542911(v=VS.85).aspx -- Ãlvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-bugs по дате отправления: