From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marko Tiikkaja <pgmail(at)joh(dot)to> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #7516: PL/Perl crash |
Date: | 2012-09-13 20:37:41 |
Message-ID: | 21173.1347568661@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Marko Tiikkaja <pgmail(at)joh(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-13 21:42:02 | Re: BUG #7516: PL/Perl crash |
Previous Message | Dave Page | 2012-09-13 20:17:19 | Re: initdb.exe changes --locale option |