Re: BUG #7516: PL/Perl crash - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #7516: PL/Perl crash
Date
Msg-id 21173.1347568661@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #7516: PL/Perl crash  (Marko Tiikkaja <pgmail@joh.to>)
Responses Re: BUG #7516: PL/Perl crash  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Dave Page
Date:
Subject: Re: initdb.exe changes --locale option
Next
From: Tom Lane
Date:
Subject: Re: BUG #7516: PL/Perl crash