Can addresses of unmodified locals wind up corrupted in setjmp/longjmp? - c

Question

If one winds up in the situation of being stuck using setjmp/longjmp (don't ask), then there are lots of nice warnings from the compiler about when you might be doing something wrong.
But with a -Wall -Wextra -pedantic build while using Address Sanitizer in Clang, I wound up with a case roughly parallel to:
void outer() {
jmp_buf buf;
ERR error;
if (setjmp(buf) ? helper(&error) : FALSE) {
// process whatever helper decided to write into error
return;
}
// do the stuff you wanted to guard that may longjmp.
// error is never modified
}
On a longjmp, looking into the helper stack frame the error pointer is null. If I look in the outer() frame it says error has been "optimized out".
It's puzzling because I'm compiling with -O0 So the "optimized out" is weird for it to be saying. But as with most things longjmp-y, I wonder what keeps the compiler from possibly making a decision on what register it's going to put the error address in ahead of time...then having that be invalidated.
Is address sanitizer punking me, or do I actually have to write something like:
void outer() {
jmp_buf buf;
ERR error;
volatile ERR* error_ptr = &error;
if (setjmp(buf) ? helper(error_ptr) : FALSE) {
// process whatever helper decided to write into error
return;
}
// do the stuff you wanted to guard that may longjmp.
// error is never modified
}
As I research this, I've noticed that jmp_bufs are not locals in any of the examples I see. Is that something you can't do? :-/
NOTE: See #AnT's answer and comments below for the "language-lawyer" issue about the setjmp() ? ... : ... construct. But what I actually had going on here turned out to be a broken longjmp call that was after the function exited. Per longjmp() docs (also: common sense), that's definitely broken; I just didn't realize that's what had happened:
If the function that called setjmp has exited, the behavior is undefined (in other words, only long jumps up the call stack are allowed)

Answer 1

Is there a reason the helper call is "embedded" into the controlling expression of if through ?: operator? This is actually a violation of the language requirements that says
7.13.1.1 The setjmp macro
4 An invocation of the setjmp macro shall appear only in one of the
following contexts:
— the entire controlling expression of a selection
or iteration statement;
— one operand of a relational or equality
operator with the other operand an integer constant expression, with
the resulting expression being the entire controlling expression of
a selection or iteration statement;
— the operand of a unary !
operator with the resulting expression being the entire controlling
expression of a selection or iteration statement; or
— the entire
expression of an expression statement (possibly cast to void).
5 If
the invocation appears in any other context, the behavior is
undefined.
The whole point of that requirement is to make sure the "unpredictable" return from setjmp, triggered by longjmp, should not land in the middle of an expression evaluation, i.e. in an unsequenced context. In your specific example it is rather obvious that from the point of view of abstract C language, variable error cannot possibly be changed by setjmp call, which opens the door for many optimizations.
It is hard to say what happened here, since helper receives a pointer &error, not error's direct value. At the surface everything seems fine from practical point of view. But formally the behavior is undefined.
In your case, you should not try to fix thing by making variables volatile, but rather should simplify the context the setjmp is used in to conform with the above requirements. Something along the lines of
if (setjmp(buf) != 0) {
helper(&error);
...
return;
}