Tom Lane wrote:
Alex Adriaanse <alex@xxxxxxxxxxxxxxxxxxx> 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
