Re: Out of memory

From: Alex Adriaanse <alex(at)innovacomputing(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: Out of memory
Date: 2008-04-04 20:24:39
Message-ID: 47F68E87.8030906@innovacomputing.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Tom Lane wrote:
> Alex Adriaanse <alex(at)innovacomputing(dot)com> writes:
>
>> Unfortunately, we do not have any core dumps from those. Is there
>> anything else I can provide to make tracing this easier? Could we use
>> the addresses mentioned in the segfault messages for anything useful?
>>
>
> Hmm, you could try attaching to a running Postgres process with gdb
> and doing "x/i 0xHEXADDRESS" --- that should at least come up with a
> routine name, unless your kernel is into address randomization ...
>
We weren't able to do this on the production server where PostgreSQL
crashed, but we did try to recreate as close a setup as possible on
another similar server with the same version of PostgreSQL 8.1.9. It is
possible that some of the libraries are different or that we're using
different binaries of the same version of PostgreSQL. Thus, it might be
possible that these particular addresses have shifted due to the
different environment and now point to irrelevant instructions. But in
case they haven't, here's the output I got:

(gdb) x/i 0x000000000049ea35
0x49ea35 <transformExpr+53>: callq 0x562c00 <check_stack_depth>

(gdb) x/i 0x000000000049ea00
0x49ea00 <transformExpr>: mov %rbx,0xffffffffffffffd0(%rsp)

(gdb) x/i 0x00000000005e7b13
0x5e7b13 <pfree+3>: mov 0xfffffffffffffff0(%rdi),%rdi

I hope this helps.

Alex

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Dunstan 2008-04-04 20:26:07 Re: modules
Previous Message Raymond O'Donnell 2008-04-04 20:22:17 Re: creating a temp table in a function