Re: BUG #6233: pg_dump hangs with Access Violation C0000005

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavel Holec" <holec(at)email(dot)cz>
Cc: "'Craig Ringer'" <ringerc(at)ringerc(dot)id(dot)au>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6233: pg_dump hangs with Access Violation C0000005
Date: 2011-10-05 01:04:29
Message-ID: 6027.1317776669@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Pavel Holec" <holec(at)email(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2011-10-05 03:28:36 Re: BUG #6233: pg_dump hangs with Access Violation C0000005
Previous Message Dave Page 2011-10-05 00:22:27 Re: [GENERAL] One-click installer, Windows 7 32-bit, and icacls.exe