Thread: BUG #6233: pg_dump hangs with Access Violation C0000005
The following bug has been logged online: Bug reference: 6233 Logged by: Holec Email address: holec@email.cz PostgreSQL version: 8.4.8 Operating system: Windows 7 Description: pg_dump hangs with Access Violation C0000005 Details: I use pg_dump on Windows 7 with: pg_dump -i -h 192.168.2.2 -p 5432 -U user -F c -b -v -f file.backup mydb Last output is: pg_dump: reading dependency data pg_dump: saving encoding = WIN1250 pg_dump: saving standard_conforming_strings = off pg_dump: saving database definition and then Windows error messagebox and pg_dump returns Access Violation C0000005 In Windows I can find out: Name of error application: pg_dump.exe, version: 8.4.8.11104, timestamp: 0x4da83e6a name of error modul: ntdll.dll, version: 6.1.7600.16695, timestamp: 0x4cc7ab44 Exception: 0xc0000005 Offset of error: 0x0005207e *On Windows XP the same pg_dump works fine! *On Windows 7 with -a (data only) pg_dump works fine too!!! Regards, Pavel
On 09/29/2011 05:18 AM, Holec wrote: > > The following bug has been logged online: > > Bug reference: 6233 > Logged by: Holec > Email address: holec@email.cz > PostgreSQL version: 8.4.8 > Operating system: Windows 7 > Description: pg_dump hangs with Access Violation C0000005 > Details: > > I use pg_dump on Windows 7 with: > pg_dump -i -h 192.168.2.2 -p 5432 -U user -F c -b -v -f file.backup mydb Does this crash happen when you back up a different database? Say, if you back up the `template1' database, does it crash then too? Is this a 32-bit or 64-bit install of Windows 7? If 64-bit, are you using a 32-bit or 64-bit build of PostgreSQL? Is there any antivirus software on the machine? If so, what type and version? Does the problem still happen if you turn it off and re-test? -- Craig Ringer
On 09/29/2011 05:18 AM, Holec wrote: > > The following bug has been logged online: > > Bug reference: 6233 > Logged by: Holec > Email address: holec@email.cz > PostgreSQL version: 8.4.8 > Operating system: Windows 7 > Description: pg_dump hangs with Access Violation C0000005 > Details: > > I use pg_dump on Windows 7 with: > pg_dump -i -h 192.168.2.2 -p 5432 -U user -F c -b -v -f file.backup > mydb >>Does this crash happen when you back up a different database? Say, if you back up the `template1' database, does it crashthen too? >>Is this a 32-bit or 64-bit install of Windows 7? If 64-bit, are you using a 32-bit or 64-bit build of PostgreSQL? >>Is there any antivirus software on the machine? If so, what type and version? Does the problem still happen if you turnit off and re-test? >>-- >>Craig Ringer My tests was on 4PC Win7 32bit and 2 PCs with Win 7 64bit and pg_dump 8.4.7 and 8.4.8 32bit. Behaviour is the same (everywherethe same db). Now I tested template1, my database without the data and new created database without the tables- the same result. Encoding I use 1250 because our system Win uses 1250 and UTF 8 made me problems with our letterswith shapes. Next my test was create new database with UTF8 and backup - same result. I tried Application Verifier from MS - output <?xml version="1.0" encoding="UTF-8" standalone="no" ?> - <avrf:logfile xmlns:avrf="Application Verifier"> - <avrf:logSession TimeStarted="2011-09-29 : 10:53:41" PID="3596" Version="2"> - <avrf:logEntry Time="2011-09-29 : 10:53:47" LayerName="Heaps" StopCode="0x6" Severity="Error"> <avrf:message>Corrupted heap pointer or using wrong heap.</avrf:message> <avrf:parameter1>47a1000 - Heap handle used in the call.</avrf:parameter1> <avrf:parameter2>6c2cf00 - Heap block involved in the operation.</avrf:parameter2> <avrf:parameter3>100 - Size of the heap block.</avrf:parameter3> <avrf:parameter4>3371000 - Heap where block was originally allocated.</avrf:parameter4> - <avrf:stackTrace> <avrf:trace>vrfcore!VerifierRegisterLayerEx+11b ( @ 0)</avrf:trace> <avrf:trace>verifier!VerifierDisableFaultInjectionExclusionRange+3e65 ( @ 0)</avrf:trace> <avrf:trace>verifier!VerifierDisableFaultInjectionExclusionRange+4131 ( @ 0)</avrf:trace> <avrf:trace>verifier!VerifierDisableFaultInjectionExclusionRange+110a ( @ 0)</avrf:trace> <avrf:trace>verifier!VerifierDisableFaultInjectionExclusionRange+12f0 ( @ 0)</avrf:trace> <avrf:trace>verifier!VerifierDisableFaultInjectionExclusionRange+3130 ( @ 0)</avrf:trace> <avrf:trace>ntdll!RtlpNtMakeTemporaryKey+48b5 ( @ 0)</avrf:trace> <avrf:trace>ntdll!EtwSetMark+e743 ( @ 0)</avrf:trace> <avrf:trace>ntdll!wcsnicmp+caa ( @ 0)</avrf:trace> <avrf:trace>vfbasics!+6cf3fe9c ( @ 0)</avrf:trace> <avrf:trace>kernel32!HeapFree+14 ( @ 0)</avrf:trace> <avrf:trace>vfbasics!+6cf41024 ( @ 0)</avrf:trace> <avrf:trace>MSVCR80!free+cd ( @ 0)</avrf:trace> </avrf:stackTrace> </avrf:logEntry> </avrf:logSession> </avrf:logfile> McAfee Security centr uninstalled... If it can helps I attach mydb without data. Pavel holec
Attachment
On 09/29/2011 05:18 AM, Holec wrote: > > The following bug has been logged online: > > Bug reference: 6233 > Logged by: Holec > Email address: holec@email.cz > PostgreSQL version: 8.4.8 > Operating system: Windows 7 > Description: pg_dump hangs with Access Violation C0000005 > Details: > > I use pg_dump on Windows 7 with: > pg_dump -i -h 192.168.2.2 -p 5432 -U user -F c -b -v -f file.backup=20 > mydb >> Does this crash happen when you back up a different database? Say, if yo= u back up the `template1' database, does it crash then too? >> Is this a 32-bit or 64-bit install of Windows 7? If 64-bit, are you usin= g a 32-bit or 64-bit build of PostgreSQL? >> Is there any antivirus software on the machine? If so, what type and ver= sion? Does the problem still happen if you turn it off and re-test? >> -- >> Craig Ringer Can anybody help me please? Maybe problem with redist msvcr80? With my app = I ship only libeay32.dll libiconv-2.dll libintl-8.dll libpq.dll ssleay32.dll zlib1.dll pg_dump.exe pg_restore.exe Pavel Holec
On 03/10/11 19:42, Pavel Holec wrote: > On 09/29/2011 05:18 AM, Holec wrote: >> >> The following bug has been logged online: >> >> Bug reference: 6233 >> Logged by: Holec >> Email address: holec@email.cz >> PostgreSQL version: 8.4.8 >> Operating system: Windows 7 >> Description: pg_dump hangs with Access Violation C0000005 >> Details: >> >> I use pg_dump on Windows 7 with: >> pg_dump -i -h 192.168.2.2 -p 5432 -U user -F c -b -v -f file.backup >> mydb > > >>> Does this crash happen when you back up a different database? Say, if you back up the `template1' database, does it crashthen too? > >>> Is this a 32-bit or 64-bit install of Windows 7? If 64-bit, are you using a 32-bit or 64-bit build of PostgreSQL? > >>> Is there any antivirus software on the machine? If so, what type and version? Does the problem still happen if you turnit off and re-test? > >>> -- >>> Craig Ringer > > Can anybody help me please? Honestly, I haven't the foggiest. I didn't see anything dodgy in the DLL list you posted earlier or any of the other info you've provided. To progress, I think you'd need to get a usable backtrace to show how and where the crash happens. Use Visual Studio (or the free Express Edition) or use windbg from Debugging Tools for Windows. Set the symbol path appropriately. Use the debugger to run pg_dump with appropriate arguments, and when it crashes, get a backtrace (stack trace) of the failure. There's some guidance on debugging on Windows here: http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows It's written for getting a stack trace of a BACKEND, and you want to get a stack trace of the CLIENT (pg_dump) so it's not quite the same, but you'll require the same tools and the same initial configuration of the symbol path etc. Instead of attaching to a running postgres.exe though you must run a new pg_dump via the debugger. -- Craig Ringer
=20 -----Original Message----- From: Craig Ringer [mailto:ringerc@ringerc.id.au]=20 Sent: Tuesday, October 04, 2011 4:44 AM To: Pavel Holec Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #6233: pg_dump hangs with Access Violation C0000005 On 03/10/11 19:42, Pavel Holec wrote: > On 09/29/2011 05:18 AM, Holec wrote: >> >> The following bug has been logged online: >> >> Bug reference: 6233 >> Logged by: Holec >> Email address: holec@email.cz >> PostgreSQL version: 8.4.8 >> Operating system: Windows 7 >> Description: pg_dump hangs with Access Violation C0000005 >> Details: >> >> I use pg_dump on Windows 7 with: >> pg_dump -i -h 192.168.2.2 -p 5432 -U user -F c -b -v -f file.backup=20 >> mydb >=20 >=20 >>> Does this crash happen when you back up a different database? Say, if y= ou back up the `template1' database, does it crash then too? >=20 >>> Is this a 32-bit or 64-bit install of Windows 7? If 64-bit, are you usi= ng a 32-bit or 64-bit build of PostgreSQL? >=20 >>> Is there any antivirus software on the machine? If so, what type and ve= rsion? Does the problem still happen if you turn it off and re-test? >=20 >>> -- >>> Craig Ringer >=20 > Can anybody help me please? >>>>Honestly, I haven't the foggiest. I didn't see anything dodgy in the DL= L list you posted earlier or any of the other info you've provided. >>>>To progress, I think you'd need to get a usable backtrace to show how a= nd where the crash happens. Use Visual Studio (or the free Express >>>>Edition) or use windbg from Debugging Tools for Windows. Set the symbol= path appropriately. Use the debugger to run >>>>pg_dump with appropriate a= rguments, and when it crashes, get a backtrace (stack trace) of the failure. >>>>There's some guidance on debugging on Windows here: >>>>http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_Post= greSQL_backend_on_Windows >>>>It's written for getting a stack trace of a BACKEND, and you want to ge= t a stack trace of the CLIENT (pg_dump) so it's not quite the same, but you= 'll require the same tools and the same initial configuration of the symbol= path etc. Instead of >>>>attaching to a running postgres.exe though you mu= st run a new pg_dump via the debugger. >>>>-- >>>>Craig Ringer Thank you for the link - perfect guide 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 f= ine. Pavel Holec
"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
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
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of mar oct 04 22:04:29 -0300 2011:
>> 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...)
> Isn't this the kind of thing that you have to enable explicitly?
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?
regards, tom lane
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
On Wed, Oct 5, 2011 at 09:24, Craig Ringer <ringerc@ringerc.id.au> wrote: > 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. =A0It'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 ne= ver > notice it. Others will crash on it consistently. It'll crash for some peo= ple > only on tuesday evenings on full moons, but only if they're in the southe= rn > 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 *a= nd* > 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, depend= ing > on the usual luck associated with double free issues. Yes. Each copy of MSVCRT will have it's own heap. But if the same version is loaded through different paths, it will just use the same copy. But when they're different versions or flags, you get two completely separate heaps in the app. Which is exactly the reason why we added that function to libpq. --=20 =A0Magnus Hagander =A0Me: http://www.hagander.net/ =A0Work: http://www.redpill-linpro.com/
-----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Wednesday, October 05, 2011 6:07 AM To: Alvaro Herrera Cc: Pavel Holec; 'Craig Ringer'; Pg Bugs Subject: Re: [BUGS] BUG #6233: pg_dump hangs with Access Violation C0000005 Alvaro Herrera <alvherre@commandprompt.com> writes: > Excerpts from Tom Lane's message of mar oct 04 22:04:29 -0300 2011: >> 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...) > Isn't this the kind of thing that you have to enable explicitly? >>> 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? >>> regards, tom lane Yes, this is the problem. libpq.dll I have built in VC6. With original I had problem with msvcr80.dll and WinSxS because my end client app is also from VC6 and I can't prepare redist msvcr for end user. Can you advice me how to do it? Pavel Holec
On 10/05/2011 09:37 PM, Pavel Holec wrote: > Yes, this is the problem. libpq.dll I have built in VC6. With original I had > problem with msvcr80.dll and WinSxS because my end client app is also from > VC6 and I can't prepare redist msvcr for end user. Can you advice me how to > do it? It would've been nice if you'd mentioned that ;-) Running a msvcrt.dll libpq with a msvcr80.dll pg_dump should work, though; Windows programs are expected to cope with insane things like mixing multiple C runtimes. It sounds like there's a bug where pg_dump doesn't use the libpq memory management functions and instead does a direct free(); changing those crash sites you found to use PQfreemem should solve the problem. Try it and see. Advise you how to do what? By the way, you should be able to use a regular libpq compiled against msvcr80.dll with your VC6 client app so long as the client app uses PQfreemem to release memory allocated by libpq. -- Craig Ringer
-----Original Message----- From: Craig Ringer [mailto:ringerc@ringerc.id.au] Sent: Thursday, October 06, 2011 2:05 AM To: Pavel Holec Cc: 'Tom Lane'; 'Alvaro Herrera'; 'Pg Bugs' Subject: Re: [BUGS] BUG #6233: pg_dump hangs with Access Violation C0000005 On 10/05/2011 09:37 PM, Pavel Holec wrote: > Yes, this is the problem. libpq.dll I have built in VC6. With original > I had problem with msvcr80.dll and WinSxS because my end client app is > also from > VC6 and I can't prepare redist msvcr for end user. Can you advice me > how to do it? >> It would've been nice if you'd mentioned that ;-) >> Running a msvcrt.dll libpq with a msvcr80.dll pg_dump should work, though; Windows programs are expected to cope with insane things like mixing multiple C runtimes. It sounds like there's a bug where pg_dump doesn't use the libpq memory management functions and instead does a direct free(); changing those crash sites you found to use PQfreemem should solve >> the problem. Try it and see. >> Advise you how to do what? >> By the way, you should be able to use a regular libpq compiled against msvcr80.dll with your VC6 client app so long as the client app uses PQfreemem to release memory allocated by libpq. >> -- >> Craig Ringer PQfreemem is what I've been thinking about - great. With SxS I see problem if customer have a clear new installation of WinXP and no msvcrt80.dll. I'm not be able to ship this dll with installaton of my client - when I use for example Inno setup. Isn't possible to have redistribute package with proper version msvcrt80.dll accord with your binaries on the wb site? Pavel Holec PS: Thank You all so much
On 10/07/2011 06:51 PM, Pavel Holec wrote: > > -----Original Message----- > From: Craig Ringer [mailto:ringerc@ringerc.id.au] > Sent: Thursday, October 06, 2011 2:05 AM > To: Pavel Holec > Cc: 'Tom Lane'; 'Alvaro Herrera'; 'Pg Bugs' > Subject: Re: [BUGS] BUG #6233: pg_dump hangs with Access Violation C0000005 > > On 10/05/2011 09:37 PM, Pavel Holec wrote: > >> Yes, this is the problem. libpq.dll I have built in VC6. With original >> I had problem with msvcr80.dll and WinSxS because my end client app is >> also from >> VC6 and I can't prepare redist msvcr for end user. Can you advice me >> how to do it? > >>> It would've been nice if you'd mentioned that ;-) > >>> Running a msvcrt.dll libpq with a msvcr80.dll pg_dump should work, > though; Windows programs are expected to cope with insane things like mixing > multiple C runtimes. It sounds like there's a bug where pg_dump doesn't use > the libpq memory management functions and instead does a direct free(); > changing those crash sites you found to use PQfreemem should solve>> the > problem. Try it and see. > >>> Advise you how to do what? > >>> By the way, you should be able to use a regular libpq compiled against > msvcr80.dll with your VC6 client app so long as the client app uses > PQfreemem to release memory allocated by libpq. > >>> -- >>> Craig Ringer > > > PQfreemem is what I've been thinking about - great. > > With SxS I see problem if customer have a clear new installation of WinXP > and no msvcrt80.dll. I'm not be able to ship this dll with installaton of my > client - when I use for example Inno setup. Why not? Just invoke the redist installer from innosetup like you would any other subprogram. > Isn't possible to have redistribute package with proper version msvcrt80.dll > accord with your binaries on the wb site? The installer does exactly that. The .zip is for expert users; it's assumed they'll be using it as part of an installer or other automated setup and are going to want control over installation of the runtime. Anyway, AFAIK you can't distribute the bare .DLL, you can only distribute Microsoft's installer for the runtime and run it as part of your install process. The .zip doesn't have an install process to run it from. Just bundle the appropriate MSVC runtime redist with your installer. You can download the redists from Microsoft. -- Craig Ringer