Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Based on https://github.com/google/sanitizers/issues/1494
kMaxSaneContextStackSize was introduced 9 years ago, and with increasing popularity of coroutines in c++ world (be that std or boost coroutines) this limitation seems a bit off.
After all, is >4Mb coroutine stack actually insane in 2022?
Could you please add a test?
compiler-rt/lib/asan/asan_interceptors.cpp | ||
---|---|---|
251 | It should probably a CHECK |
I guess some sanity check would be good, but since we get are not guessing this value but getting it directly from the OS, it's fine either way?
In boost::Coroutine2 stack size might be user-provided and i am not sure if there is a limitation at all.
Sure, but could you please suggest an appropriate place for that and where to look for references? - i'm not familiar with the codebase
Take a look at:
compiler-rt/test/asan/TestCases/Linux/swapcontext_test.cpp
compiler-rt/test/asan/TestCases/Linux/swapcontext_annotation.cpp
You may consider to modify them, or just fork and throw away unneeded stuff.
I expect new test is just simplest piece of code which use this function and fails without patch and passes with the patch.
Right, same as ex. the size argument in memset. If it's wrong, we crash, but that's the user's fault. As opposed to some heuristic to detect stack limits, or that thing where we peek at glibc internals to parse the thread header which keeps changing between versions...
Added a test, could you please have a look?
It's not exactly the simplest piece of code unfortunately, but i guess it's not that bad:
it resembles pretty close to what boost.Coroutine2 does, and fixing that was the motivation for the patch.
P.S. I did check that it fails without the patch, that could be seen in builds history
Thanks, LGTM.
compiler-rt/test/asan/TestCases/Linux/swapcontext_annotation.cpp | ||
---|---|---|
68 | I moved formatting into a separate patch |
I uploaded it with slight modifications here. Hopefully it will work with D130218. Maybe you can check both, or even test in your environment.
It's not perfect, but better then we had before.
It should probably a CHECK
e.g. CHECK_LE(ssize, 1<<28)