Tom Lane wrote:
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.
It's like a double-free - you often get away with it. Some people will
never notice it. Others will crash on it consistently. It'll crash for
some people only on tuesday evenings on full moons, but only if they're
in the southern hemisphere and using a laptop with an exactly 1.8GHz
CPU. Etc.
Add the "interesting" variety of Windows environments and configurations
that exist and it's not surprising to see this sort of issue pop up only
occasionally.
In particular, if your libpq and pg_dump link to the exact same msvcrt
*and* that's a dynamic (dll) runtime not a static runtime, you'll get
away with this. If they link to the same static runtime it'll crash. If
they link to different dynamic runtimes - different versions, different
thread/debug options, etc - then you still might get away with it or
might not, depending on the usual luck associated with double free issues.
I'm looking at our docs for PQfreemem:
Frees memory allocated by libpq, particularly PQescapeByteaConn,
PQescapeBytea, PQunescapeBytea, and PQnotifies. It is
particularly important that this function, rather than free(),
be used on Microsoft Windows. This is because allocating memory
in a DLL and releasing it in the application works only if
multithreaded/single-threaded, release/debug, and static/dynamic
flags are the same for the DLL and the application. On
non-Microsoft Windows platforms, this function is the same as
the standard library function free().
I have no idea how accurate or complete that third sentence is;
but perhaps the OP is trying to use a libpq.dll that was built
separately from his pg_dump executable?
Yeah, or if pg_dump is in a different directory to libpq with a
different copy of msvcrt I think you can be bitten by this too.
free()ing RAM malloc'd in a different DLL/EXE is just plain wrong in
Windows anyway. If this wasn't caught by automated tests then tests may
need to be run on -debug builds in future.
--
Craig Ringer
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
