On Sun, Jan 25, 2015 at 02:02:47PM -0500, Tom Lane wrote: > and compared the assembly language generated with and without adding > "volatile" to Tmpfd's declaration. Without "volatile" (ie, in the > code as shipped), gcc optimizes away the assignment "Tmpfd = -1" > within PG_TRY, and it also optimizes away the if-test in PG_CATCH, > apparently believing that control cannot transfer from inside the > PG_TRY to the PG_CATCH. This is utterly wrong of course. The issue > is masked because we don't bother to test for a failure return from the > second close() call, but it's not hard to think of similar coding > patterns where this type of mistaken optimization would be disastrous. > (Even here, the bogus close call could cause a problem if we'd happened > to open another file during the last part of the PG_TRY stanza.)
<snip>
> This is scary as hell. I intend to go around and manually audit
> every single PG_TRY in the current source code, but that is obviously
> not a long-term solution. Anybody have an idea about how we might
> get trustworthy mechanical detection of this type of situation?
It's a bit of a long shot, but perhaps if you put something like:
asm volatile("":"":"":"memory")
at the beginning of the catch-block it might convince the compiler to
forget any assumptions about what is in the local variables...
Hope this helps,
--
Martijn van Oosterhout <klep...@svana.org> http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
-- Arthur Schopenhauer
signature.asc
Description: Digital signature
