Clang incorrectly handles exceptions in presence of stack aligned variables

[llvmbot]

Bugzilla Link	11468
Resolution	FIXED
Resolved on	Jul 30, 2012 03:55
Version	trunk
OS	All
Attachments	Clang exceptions test
Reporter	LLVM Bugzilla Contributor
CC	@asl,@d0k,@echristo,@efriedma-quic,@eugenis,@kcc

Extended Description

On fresh clang from trunk.
Reproducible both on Mac OS and Linux.

Clang seem to incorrectly restore value of callee-safe registers
during stack unwinding (when exception is thrown). This happens in
presence of aligned stack variables. Clang inserts asm instruction that
aligns %rsp but this isn't reported to unwinder. See this reproducer:

$ cat exception_test.cc
#include <stdio.h>

void TouchR15AndThrow(const char& arg) {
volatile int n attribute((aligned(32))) = 0;
asm volatile ("nop" : : : "r15"); // force to save r15 on stack
throw arg;
}

int main() {
register int *a asm ("r15");
fprintf(stderr, "before throw: %p\n", a);
try {
TouchR15AndThrow('c');
} catch (const char&) { }
fprintf(stderr, "after catch: %p\n", a);
return 0;
}
$ ../build/Release+Asserts/bin/clang++ -O2 exception_test.cc
$ ./a.out
before throw: 0x7fff5fbff968
after catch: 0x7fff702de650

More data, including parts of objdump and DWARF can be found here:
: http://code.google.com/p/address-sanitizer/issues/detail?id=13#c1

[efriedma-quic]

Applying a register name to a variable that isn't used in an inline asm doesn't actually do anything.

[d0k]

To quote http://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html

Local register variables in specific registers do not reserve the registers, except at the point where they are used as input or output operands in an asm statement and the asm statement itself is not deleted.

[llvmbot]

Ouch, sorry for that. I tried to make another reproducer, please take a look:
$ cat exception_test.cc
#include <stdio.h>

attribute((noinline))
void TouchR15AndThrow(const char& arg) {
volatile int n attribute((aligned(32))) = 0;
asm volatile ("nop" : : : "%r15"); // force to save r15 on stack
throw arg;
}

int main() {
// Set r15 value
int a = 42;
asm ("movq %0, %%r15;\n\t" : : "g"(a) : "%r15");
// Output value of r15
int b;
asm ("movq %%r15, %0;\n\t" : "=g" (b) : : "%r15");
fprintf(stderr, "before = %d\n", b);
try {
TouchR15AndThrow('c');
} catch (const char&) { }
// Output value of r15 again
asm ("movq %%r15, %0;\n\t" : "=g" (b) : : "%r15");
fprintf(stderr, "after = %d\n", b);
return 0;
}

$ ../build/Release+Asserts/bin/clang++ -O2 exception_test.cc
$ ./a.out
before = 42
after = 0

there is no instruction that changes value in %r15, but it is incorrectly restored after exception is caught.

[llvmbot]

From the EH ABI:

"The unwind runtime will likely have modified the stack (e.g. popped frames from it) or register context, or landing pad code may have corrupted them. As a result, the the caller of _Unwind_RaiseException can make no assumptions about the state of its stack or registers."

So basically we cannot rely upon any register values being valid except for those we know are restored via the unwinder. Sorry about that.

[llvmbot]

But Clang does make such assumptions, not we. Here's a part of actual code that caused a problem (not a reproducer with manual register handling):

int main() {
const Action a;
fprintf(stderr, "&a before = %p\n", &a);
try {
a.DoSomething(); // throws exception inside
} catch (const char&) { }
fprintf(stderr, "&a final = %p\n", &a);
return 0;
}

These code outputs:
&a before = 0x7fff1300e2c0
&a final = 0x101010101010101

Objdump shows that Clang stores address of local variable "a" in a register "r15", and use the value in this register every time "a" is accessed. This seems valid, because "r15" is callee-safe. Certainly, call to EH routines (like "_Unwind_RaiseException") garbles the stack and registers, after all, their goal is to restore the context. But in this case context is restored incorrectly, and the program behaves unexpectedly. Clang depends on the fact that try-catch block won't change a register, which is not the case.

[asl]

Yes, we should definitely check this. When stack is realigned then all the variables should be saved / restored relative to frame pointer.

[llvmbot]

Yes, we should definitely check this. When stack is realigned then all the
variables should be saved / restored relative to frame pointer.

ARM does something like this via magic (i.e., explicitly doing it). But that's because of the ARM ABI. The EH ABI is rather clear on this point, with regards to the stack and registers. Also, I don't get the same result that you do:

$ cat t.cpp
#include <stdio.h>

struct Action {
Action() {}
void DoSomething() const { throw 'c'; }
};

int main() {
const Action a;
fprintf(stderr, "&a before = %p\n", &a);
try {
a.DoSomething(); // throws exception inside
} catch (const char&) { }
fprintf(stderr, "&a final = %p\n", &a);
return 0;
}

$ clang++ -O2 t.cpp && ./a.out
&a before = 0x7fff63f8dae8
&a final = 0x7fff63f8dae8

[llvmbot]

It is hard to find a good enough reproducer: for that you need:

1. explicitly introduce aligned stack variables.
2. persuade Clang to store address of local variable in one of callee-save registers. However, I still don't see why reproducer in comment4 is invalid, as I don't use EH ABI (call any Unwind* functions), I just use "try-catch" and "throw" constructions.

You may also try this program:
$ cat t.cc
#include <stdio.h>
#include <string.h>

class Action {
public:
Action() {}
attribute((noinline))
void Throw(const char& arg) const {
volatile int attribute((aligned(32))) n = 0; // aligned stack variable
asm volatile ("nop" : : : "rbx"); // force to save %rbx on stack
throw arg;
}
};

int main() {
struct {
char arr1[32];
Action a;
char arr2[24 + 32];
} zzz;
fprintf(stderr, "&a before = %p\n", &zzz.a);
try {
zzz.a.Throw('c');
} catch (const char&) {
fprintf(stderr, "&a in catch = %p\n", &zzz.a);
}
fprintf(stderr, "&a final = %p\n", &zzz.a);
return 0;
}
$ clang++ -O2 t.cc
$ ./a.out
&a before = 0x7fff7af03b68
&a in catch = 0x7f5b522f4210
&a final = 0x7f5b522f4210

But the error emerges once in 3-4 runs (without recompiling a source).

[kcc]

I've added the original Alexey's test case as projects/compiler-rt/lib/asan/tests/asan_exceptions_test.cc
(r145839).

Using this repro the bug can be reproduced with "-faddress-sanitizer -O2" on both Linux and Mac.

% ./build/Release+Asserts/bin/clang++ -faddress-sanitizer projects/compiler-rt/lib/asan/tests/asan_exceptions_test.cc -O2 &&./a.out
&a before = 0x7fff5fbffb00
PrintString called!
&a in catch = 0x1fffebf7ff5c
&a final = 0x1fffebf7ff5c

(On Mac -faddress-sanitizer is completely usable in TOT if you checkout projects/compiler-rt and do the makefiles build)

[llvmbot]

2. persuade Clang to store address of local variable in one of callee-save
   registers. However, I still don't see why reproducer in comment4 is invalid, as
   I don't use EH ABI (call any Unwind* functions), I just use "try-catch" and
   "throw" constructions.

Of course, it's the API calls which call the Unwind* functions, not the user. I.e., the __cxa_throw call, which is generated by the front-end when it encounters something like a C++ 'throw'.

[llvmbot]

Did you have a chance to look at this issue yet?

[llvmbot]

Did you have a chance to look at this issue yet?

I cannot reproduce the failure with any of the test cases given. Even running them several times in a row.

[llvmbot]

Hm, I tested reproducer from comment9 on Linux and Mac. What system do you use? Also, could you please check this:
./build/Release+Asserts/bin/clang++ -faddress-sanitizer projects/compiler-rt/lib/asan/tests/asan_exceptions_test.cc -O2 && ./a.out

[llvmbot]

Did anyone has a chance to look at this bug yet? Program from comment9 still occasionally works incorrectly on my machine (trunk r148235).

[llvmbot]

Hm, I tested reproducer from comment9 on Linux and Mac. What system do you use?
Also, could you please check this:
./build/Release+Asserts/bin/clang++ -faddress-sanitizer
projects/compiler-rt/lib/asan/tests/asan_exceptions_test.cc -O2 && ./a.out

I'm using a Mac.