From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Tom Turelinckx" <tom(at)turelinckx(dot)be> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Bus error in formatting.c NUM_numpart_to_char (9.4.12, 9.6.3, sparc) |
Date: | 2017-06-22 18:51:44 |
Message-ID: | 9547.1498157504@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"Tom Turelinckx" <tom(at)turelinckx(dot)be> writes:
> Tom Lane wrote:
>> Anyway, find those annotation(s) and send us all the text for that area and maybe a few dozen lines on either side.
> Summary for the current issue, against 9.4.12.
Hm. The code seems about the same except that the compiler has changed
a few register assignments. In both cases, the crash has to be coming
from the load instruction in line 4419, unless gdb is totally lying to
us about where the crash is. And that register was loaded up at line
4389:
.loc 1 4389 0
ld [%fp-80], %g3
ld [%g3+12], %g2
...
.loc 1 4419 0
ld [%g3+8], %g2
cmp %g2, -1
(The "patched" code uses %g4 instead, but otherwise is the same.)
Now, the value loaded has to be a valid pointer, because the load
from [%g3+12] didn't crash. And nothing in the straight-line
code sequence changed %g3. But we aren't seeing all of the complicated
if-test at line 4413. It looks to me like the compiler has put some
of it out-of-line, at labels .LL697 and .LL726 (or .LL692 and .LL693
in the "patched" assembly). I am guessing that some part of those
code sequences must be trashing %g3 before jumping back to this
sequence at .LL553 or .LL715.
Maybe you could extract those bits too? Or if you prefer, just send me
the whole .s files off-list.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-22 21:09:29 | Re: Bus error in formatting.c NUM_numpart_to_char (9.4.12, 9.6.3, sparc) |
Previous Message | Alvaro Herrera | 2017-06-22 17:22:21 | Re: Beta 10 parser error for CREATE STATISTICS IF NOT EXISTS |