-----Original Message----- From: Craig Ringer [mailto:ring...@ringerc.id.au] 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: ho...@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 > > 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 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 fine. Pavel Holec -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
