On Wed, Jan 10, 2018 at 11:08 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Glauco Torres <torres.glauco@gmail.com> writes:
>> (gdb) bt
>> #0 ckpt_buforder_comparator (pa=pa@entry=0x7f6fa9ef4b2c,
>> pb=pb@entry=0x1be06d2d06644)
>> at bufmgr.c:4137
>> #1 0x0000000000801268 in med3 (a=0x7f6fa9ef4b2c "\177\006",
>> b=0x1be06d2d06644 <Address 0x1be06d2d06644 out of bounds>,
>> c=0x2fc9dfbb1815c <Address 0x2fc9dfbb1815c out of bounds>, cmp=0x6a4d20
>> <ckpt_buforder_comparator>)
>> at qsort.c:107
>> #2 0x0000000000801621 in pg_qsort (a=0x7f6fa9ef4b2c, a@entry=0x7f6fa9ea8380,
>> n=<optimized out>, es=es@entry=20, cmp=cmp@entry=0x6a4d20
>> <ckpt_buforder_comparator>) at qsort.c:157
>> #3 0x00000000008015e2 in pg_qsort (a=0x7f6fa9ea8380, n=<optimized out>,
>> n@entry=111473, es=es@entry=20, cmp=cmp@entry=0x6a4d20
>> <ckpt_buforder_comparator>) at qsort.c:203
>> #4 0x00000000006a81cf in BufferSync (flags=flags@entry=128) at
>> bufmgr.c:1863
>
> Hm. I'm not normally one to jump to the conclusion that something is a
> compiler bug, but it's hard to explain this stack trace any other way.
> The value of "n" passed to the inner invocation of pg_qsort should not
> have been more than 29914, but working from either the value of d or the
> value of pn leads to the conclusion that it was 0x7f6fa9f3a470, which
> looks a lot more like an address in the array than a proper value of n.
>
> I suppose this might be due to a corrupted copy of the postgres executable
> rather than an actual compiler bug. Did you build it yourself?
>
> BTW, I notice that ckpt_buforder_comparator assumes it can't possibly
> see the same block ID twice in the array, which I think is an
> unsupportable assumption. But I cannot see a way that that could lead
> to a crash in pg_qsort --- at worst it might cause a little inefficiency.
simple
SELECT version();
...can give a lot of hints on who/what compiled the database if you don't know.
merlin
