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

-----Original Message-----
From: Craig Ringer [mailto:ringerc(at)ringerc(dot)id(dot)au]
Sent: Tuesday, October 04, 2011 4:44 AM
To: Pavel Holec
Cc: pgsql-bugs(at)postgresql(dot)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(at)email(dot)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