Re: Out of memory - Mailing list pgsql-general

From Alex Adriaanse
Subject Re: Out of memory
Date
Msg-id 47F68E87.8030906@innovacomputing.com
Whole thread Raw
In response to Re: Out of memory  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Out of memory  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Tom Lane wrote:
> Alex Adriaanse <alex@innovacomputing.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


pgsql-general by date:

Previous
From: Raymond O'Donnell
Date:
Subject: Re: creating a temp table in a function
Next
From: Alvaro Herrera
Date:
Subject: Re: creating a temp table in a function