Re: BUG #6233: pg_dump hangs with Access Violation C0000005 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #6233: pg_dump hangs with Access Violation C0000005
Date
Msg-id 6027.1317776669@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #6233: pg_dump hangs with Access Violation C0000005  ("Pavel Holec" <holec@email.cz>)
Responses Re: BUG #6233: pg_dump hangs with Access Violation C0000005  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-bugs
"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.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Dave Page
Date:
Subject: Re: [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #6233: pg_dump hangs with Access Violation C0000005