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
