=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
