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 21:42:02 |
Message-ID: | 22390.1347572522@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> 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.
Filed at https://bugzilla.redhat.com/show_bug.cgi?id=857236
On the good side: developing a minimal test case showed me that the code
is incorrectly compiled only if perl.h has been included. (WTF? No,
I don't know why.) So at least this gcc bug should only be affecting
plperl.c and not the rest of postgres.
> 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.
But, of course, pg_re_throw() already is marked noreturn.
A probably less costly solution than marking current_call_data volatile
is just to make it not-static.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-13 21:58:52 | Re: BUG #7516: PL/Perl crash |
Previous Message | Tom Lane | 2012-09-13 20:37:41 | Re: BUG #7516: PL/Perl crash |