Re: Out of memory
От | Alex Adriaanse |
---|---|
Тема | Re: Out of memory |
Дата | |
Msg-id | 47F68E87.8030906@innovacomputing.com обсуждение исходный текст |
Ответ на | Re: Out of memory (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Out of memory
|
Список | 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 по дате отправления: