Re: BUG #7516: PL/Perl crash

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #7516: PL/Perl crash
Дата
Msg-id 21173.1347568661@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #7516: PL/Perl crash  (Marko Tiikkaja <pgmail@joh.to>)
Ответы Re: BUG #7516: PL/Perl crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Marko Tiikkaja <pgmail@joh.to> writes:
> On 13/09/2012 19:48, Tom Lane wrote:
>> Hm, I wonder if it's Ubuntu-specific?  What Perl version is that exactly?

> We've reproduced it on both 5.14.2 and 5.16.1.

Meh.  I've managed to reproduce it on the fifth system I tried.  I don't
think it's got anything to do with the Perl version, but with the gcc
version (which is 4.7.0 on this machine).  Apparently, very recent gcc
versions are willing to throw away this line of code:

        PG_CATCH();
        {
----->          current_call_data = save_call_data;
                activate_interpreter(oldinterp);
                PG_RE_THROW();
        }
        PG_END_TRY();

        current_call_data = save_call_data;
        activate_interpreter(oldinterp);
    return retval;

Apparently the reasoning is that current_call_data is a static and
therefore the compiler can see everything that can happen to it and
therefore this store into current_call_data is dead code, since the
store six lines below will replace it.  Sigh.  I shall file a bug,
but I've found that the current crop of gcc maintainers are quite
likely to reject such reports.

We could fix the immediate problem by marking current_call_data volatile
(I've tested that this makes the problem go away on F17), but I think
what we'd better do instead is mark pg_re_throw() as noreturn.
Hopefully that will also prevent this misoptimization, as well as
similar ones that might be happening elsewhere.

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: initdb.exe changes --locale option
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #7516: PL/Perl crash