Обсуждение: BUG #8461: PostgreSQL 9.3 pg_dump heap corruptions
The following bug has been logged on the website:
Bug reference: 8461
Logged by: Benjamin Wassermann
Email address: benny@hegne.de
PostgreSQL version: 9.3.0
Operating system: Windows
Description:
Hi!
We are trying to build our own PostgreSQL 9.3 using Visual Studio 2005 on
Windows XP.
If we use the created pg_dump we get some âHeap Corruptionsâ and no database
dump will be created.
When we use the precomiled binaries from PostgreSQL 9.3 and use this pg_dump
we do NOT get any heap corruption and it works as expected.
To reproduce the bug you need a Microsoft Visual Studio 2005 with Version
8.0.50727.42.
Buildsteps:
1. Download the postgresql sources 9.3
2. Open a visual studio commandline and change to folder
"postgresql-9.2.3\src\tools\msvc". Execute the command "perl mkvcbuild.pl"
(make sure "ActivePerl" is installed, where using version "5.12.2 Build
1202").
3. In the root folder is now a pgpsql.sln, which u can open in visual
studio
4. Now change the "Build-Target" to Release
5. Now build the Projects in following steps and configuartions
libpgport:
General > Use of MFC: "Use MFC in a Static Libary"
Libarian: Ingore Specific Libary "Nafxcwd.lib" and "Libcmtd.lib"
-> Build
libpqtypes:
General > Use of MFC: "Use MFC in a Static Libary"
-> Build
libpq:
General > Use of MFC: "Use MFC in a Static Libary"
Linker > Additional Dependencies: "ShFolder.lib" and "Advapi32.lib"
-> Build
libecpg:
General > Use of MFC: "Use MFC in a Static Libary"
-> Build
libpgcommon:
General > Use of MFC: "Use MFC in a Static Libary"
-> Build
psql:
General > Use of MFC: "Use MFC in a Static Libary"
Linker > Additional Dependencies: "Advapi32.lib"
Rename the Function _dosmaperr to _test_dosmaperr
-> Build
If there is a error like: "ERROR: psqlscan.c could not be found" just do
the following:
Open a commandline and call "flex.exe "<Path to
sources>\postgresql-9.2.3\src\bin\psql\psqlscan.l"
(http://gnuwin32.sourceforge.net/install.html). Now copy the created file to
"\postgresql-9.2.3\src\bin\psql\psqlscan.c".
-> Build
pg_dump:
General > Use of MFC: "Use MFC in a Static Libary"
Linker > Additional Dependencies: "Advapi32.lib" and "zlib.lib" (path
example with default installation: "C:\Programme\GnuWin32\lib\zlib.lib")
C/C++ > Preprocessor Definitions: "HAVE_LIBZ"
C/C++ > Additional Include Directories: C:\Programme\GnuWin32\include
-> Build
Now we have installed a PostgreSQL Server 9.3 on the same machine.
In Visual Studio we defined as "Command Arguments" the following:
"-h "localhost" -p 5432 -U postgres -f "C:\test.bak" -F c test"
Now start debugging and u will get the Heap corruption in Visual Studio.
Exactly u will get the following ASSERTION:
---------------------------
Microsoft Visual C++ Debug Library
---------------------------
Debug Assertion Failed!
Program: ...
File: dbgheap.c
Line: 1252
Expression: _CrtIsValidHeapPointer(pUserData)
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
(Press Retry to debug the application)
---------------------------
Abbrechen Wiederholen Ignorieren
---------------------------
Which is caused from the Function "dumpFunc" at line 9942 ff.
...
free(funcsig);
...
Hope you can reproduce this Bug.
Is there a workaround we could use?
Regards
Benjamin
We finally find out why this problem occurs.
PG_dump use some Functions like
initPQExpBuffer(..)
from the libpq.dll.
In this function "initPQExpBuffer(...)" are some memory allocated with
malloc(...).
(File: "pg_dump.c", line 9366)
After the function is successfully dumped to backup file, there is a
"free(...)" in Function "dumpFunc" at line 9942 ff.
...
free(funcsig);
...
but the PG_dump.exe cant free memory which is allocated by libpq.dll.
To fix this problem the "libpq.dll" need a new function named
"deletePQCharPointer()"
File: "pqexpbuffer.h"
Line: 188
> extern void deletePQCharPointer(char *pointer);
The definition of the function is:
File: "pqexpbuffer.c"
Line: 378
> void
> deletePQCharPointer(char *pointer)
> {
> if (pointer)
> {
> free(pointer);
> }
> }
Then add the function to the exported functions in the def files
File: "libpqddll.def"
Line: 169
> deletePQCharPointer @ 166
File: "blibpqdll.def"
Line: 169
> _deletePQCharPointer @ 166
File: "blibpqdll.def"
Line: 337
> deletePQCharPointer = _deletePQCharPointer
We have successfully tested the new function and it would be nice if this is
in a future release of postgresql ;)
Regards
Ben
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/BUG-8461-PostgreSQL-9-3-pg-dump-heap-corruptions-tp5771445p5774487.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
On 10/14/13 2:31 PM, Benjamin Wassermann wrote: > but the PG_dump.exe cant free memory which is allocated by libpq.dll. > > To fix this problem the "libpq.dll" need a new function named > "deletePQCharPointer()" libpq already provides that functionality in PQfreemem(): http://www.postgresql.org/docs/9.3/static/libpq-misc.html. Regards, Marko Tiikkaja
On Mon, Oct 14, 2013 at 05:31:46AM -0700, Benjamin Wassermann wrote:
> We finally find out why this problem occurs.
>
> PG_dump use some Functions like
> initPQExpBuffer(..)
> from the libpq.dll.
>
> In this function "initPQExpBuffer(...)" are some memory allocated with
> malloc(...).
> (File: "pg_dump.c", line 9366)
>
> After the function is successfully dumped to backup file, there is a
> "free(...)" in Function "dumpFunc" at line 9942 ff.
> ...
> free(funcsig);
> ...
>
> but the PG_dump.exe cant free memory which is allocated by libpq.dll.
>
> To fix this problem the "libpq.dll" need a new function named
> "deletePQCharPointer()"
Actually, there are many places where Windows binaries free memory
allocated by libpq. This is possible because of the way we compile
libpq and the binary. Our PQfreemem() manual page has the details
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().
If the free() was not working for you, my guess is that you had
mismatched flags for libpq and pg_dump compiles.
However, you were right that there was a memory leak in that area of the
code related to how funcfullsig and aggfullsig were conditionally
assigned values, but not freed.
The attached patch fixes this memory leak; not sure if this should be
back-patched.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
Вложения
On Fri, Feb 14, 2014 at 11:01:11PM -0500, Bruce Momjian wrote: > Actually, there are many places where Windows binaries free memory > allocated by libpq. This is possible because of the way we compile > libpq and the binary. Our PQfreemem() manual page has the details > > 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(). > > If the free() was not working for you, my guess is that you had > mismatched flags for libpq and pg_dump compiles. > > However, you were right that there was a memory leak in that area of the > code related to how funcfullsig and aggfullsig were conditionally > assigned values, but not freed. > > The attached patch fixes this memory leak; not sure if this should be > back-patched. Patch applied. I have not backpatched this. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +