Alex Adriaanse <alex@innovacomputing.com> writes:
> ... 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
Hmm, not exactly what I was expecting to see. The last one looks like
someone passed garbage (maybe a NULL) to pfree; which would be a bug but
it's not clear how memory pressure would result in that, and without
knowing where pfree was called from we're not going to be able to get
far investigating.
The first two both seem like they could only be explained by running out
of execution stack space. 8.1 takes the max_stack_depth setting you
tell it as gospel, so a core dump right there is possible if you set
max_stack_depth too large, but you didn't mention having changed it.
In any case it's not clear why you'd get a transient spate of problems
like that, unless the system was handlng especially (and unreasonably)
complicated queries for awhile. Did you query the client about whether
their workload could have been unusual during this episode?
Of course this is all just speculation since we can't trust the
addresses completely.
regards, tom lane
