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 <kleptog@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