From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Glauco Torres <torres(dot)glauco(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Segmentation fault with core dump |
Date: | 2018-01-10 17:41:00 |
Message-ID: | 17271.1515606060@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Tom Lane wrote:
>> 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.
> Hmm, is this something that can be explained by using a different
> postgres executable in GDB than the one that produced the core file?
That would result in nonsensical gdb output, most likely; but Glauco's
trace is internally consistent enough that I doubt gdb is lying to us.
In any case, the crash is an observable fact :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-01-10 17:47:42 | Re: Segmentation fault with core dump |
Previous Message | Alvaro Herrera | 2018-01-10 17:37:42 | Re: Segmentation fault with core dump |