IMPLEMENT_RANDOMIZE_STACK potential race condition? #1130

The macro IMPLEMENT_RANDOMIZE_STACK uses a "static char" to store the number of loops. This is shared between threads (it is used in at least 9 different thread functions) and operations such as '--' are not guaranteed to be atomic. If multiple threads end up in this loop at the same time, there could be executions that would result in an infinite loop (or at least, unreasonably deep stacks that exceed the hardcoded limit of 20).

To fix this we could use thread-local storage here (__thread /__declspec(thread) depending on the compiler...). Or find an alternative for this... slightly crazy macro.

I remember someone once mentioned that such stack randomization is even optimized away by recent compilers, so I had at a look at the generated code. My assembly-fu is not that good, but from what I understand, ThreadMessageHander for example is compiled to not more than a strangely-ordered loop. A form of tail-recursion optimization, I assume. It's easy to avoid this optimization, by adding a effectful statement after the recursive call in the IMPLEMENT_RANDOMIZE_STACK, but given that we also use -fstack-protector already, maybe we can drop this construct altogether?

That's a pretty smart optimizer!

Hmm if the goal is to displace the stack pointer with an arbitrary amount we could also use alloca() with a random amount.

Is there an option to enable ASLR with GCC, this should do the same right?

Closing this, I don't think it's an actual problem as every usage of the macro creates a new static variable which is only used within that thread.