Tom Lane wrote: > Glauco Torres <torres.glauco@xxxxxxxxx> 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? Hmm, is this something that can be explained by using a different postgres executable in GDB than the one that produced the core file? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
