Re: [BUGS] Bus error in formatting.c NUM_numpart_to_char (9.4.12, 9.6.3, sparc)
От | Tom Lane |
---|---|
Тема | Re: [BUGS] Bus error in formatting.c NUM_numpart_to_char (9.4.12, 9.6.3, sparc) |
Дата | |
Msg-id | 9547.1498157504@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] Bus error in formatting.c NUM_numpart_to_char (9.4.12, 9.6.3, sparc) ("Tom Turelinckx" <tom@turelinckx.be>) |
Список | pgsql-bugs |
"Tom Turelinckx" <tom@turelinckx.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 0ld [%fp-80], %g3ld [%g3+12], %g2....loc 1 4419 0ld [%g3+8], %g2cmp %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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: