Glauco Torres <torres.glauco@gmail.com> writes:
> Today I left to generate more core-dump, follow the return,
> (gdb) bt
> #0 tbm_comparator (left=left@entry=0x1d5ca08, right=right@entry=0x3acdb70)
> at tidbitmap.c:1031
> #1 0x0000000000801268 in med3 (a=0x1d5ca08 "\350>\337\001", b=0x3acdb70
> <Address 0x3acdb70 out of bounds>, c=0x583ecd8 <Address 0x583ecd8 out of
> bounds>, cmp=0x603ca0 <tbm_comparator>) at qsort.c:107
> #2 0x0000000000801621 in pg_qsort (a=0x1d5ca08, n=<optimized out>,
> n@entry=10477,
> es=es@entry=8, cmp=cmp@entry=0x603ca0 <tbm_comparator>) at qsort.c:157
> #3 0x0000000000604a7b in tbm_begin_iterate (tbm=tbm@entry=0x1dd8a00) at
> tidbitmap.c:635
Oh ho! I was wondering to myself "if pg_qsort is broken, why isn't
his system falling over everywhere?". The answer evidently is
"yes, it is falling over everywhere". This symptom looks pretty much
like what you had before, ie far-out-of-range addresses getting passed
to med3(), but the qsort call site is completely different.
Since you've eliminated the idea that the executable file per se
is different from your working servers, I think we're now down to
the conclusion that there's something flaky about the hardware
on this server. Maybe it's misexecuting integer divide every so
often --- though it's hard to guess why only pg_qsort would be
affected.
regards, tom lane
