Asan doesn't work with exceptions on Windows #749
Comments
|
A simpler example: With ASan this prints "caught 1561575566", and "caught 1" without. I think ASan instrumentation is interfering with catch object stack objects. It's attempting to instrument them, when they must appear at some fixed offset from the stack pointer. In your example, this interference results in a null dereference while evaluating |
|
Also, ASan instrumentation isn't inserting calls into EH pads with the right funclet token bundle, so any attempts to do ASan checks inside funclets will be removed by WinEHPrepare. This will require significant work to fix. |
|
@rnk Are exceptions supported on Windows? |
|
No, the comment about EH pads and tokens is still relevant. It is more likely that we will change the way windows EH funclets work to make it so that ASan's instrumentation is more naturally compatible with Windows EH than that we will fix ASan to deal with the current system. |
|
Is there any workaround for this problem? Would __try __except __throw usage help here? |
Well, the workaround would be to apply
What did you have in mind? Functions that use SEH (__try / __except) already have asan disabled for other reasons, so I don't think it would help. |
|
Damn, I've spent a whole day trying to understand what's failing in my code and I finally got here. I think there should be at least some compiler warning about this. |
It doesn't sound very nice to not sanitize the whole functions, so a slightly better workaround is to wrap the try/catch in a lambda and execute it immediately. #include <iostream>
#include <exception>
int main() {
[]() __attribute__((no_sanitize_address)) {
try {
throw std::runtime_error("test");
} catch (const std::runtime_error &ex) {
std::cout << ex.what() << std::endl;
}
}();
std::cout << "end" << std::endl;
return 0;
}Unfortunately, handling the exception in a separate function doesn't really help, as it only reduces the length of the ASan message. If this #include <iostream>
#include <exception>
int main() {
try {
throw std::runtime_error("test");
} catch (const std::runtime_error &ex) {
std::cout << ex.what() << std::endl;
}
std::cout << "end" << std::endl;
return 0;
}
results in This #include <iostream>
#include <exception>
__attribute__((no_sanitize_address)) void handle(const std::runtime_error &ex) noexcept {
std::cout << ex.what() << std::endl;
}
int main() {
try {
throw std::runtime_error("test");
} catch (const std::runtime_error &ex) {
handle(ex);
}
std::cout << "end" << std::endl;
return 0;
}results in |
|
And with more experementation we can see a wide array of interesting error messages For code with using
For custom exception with class CustomException : public std::exception {
const char *message;
public:
CustomException(const char *msg) : message(msg) {}
const char *what() const noexcept override { return message; }
};
Gibberish does not change between runs and change only between compilations And those cases compile and run perfectly fine without |
|
Also I check on several of the cases, |
|
I have finalized a |
|
I can't speak to our help with the detailed problems you are having, but we can definitely improve the way this incompatibility is handled. @smeenai , didn't we have some solution to this problem for other instrumentation tools? Alternatively, we can power-off ASan for functions using EH automatically, it's easy to detect a personality function and the presence of catchpad/cleanuppad. |
|
There's https://reviews.llvm.org/D143108, but it seems to have slipped through the cracks on everyone's ends. Would that help here? |
|
Nice, that does look like a proper fix. |
|
I'm sure the patch may help, but it seems to only be a part o the problem (trying the repro above with the patch still fails). |
This still cannot be enabled in asan mode due to google/sanitizers#749 still not being solved and the proposed workaround not actually working.
Workaround for google/sanitizers#749 Downstream commit - #453999
That review was redone as a PR : llvm/llvm-project#82533 It fixes one part of this issue: now Asan on Windows target should at least support the case of |
and others
If I run this code with -fsanitize=address then I get an error message like below.
What is the status of exception support on Windows by address sanitizer ?
The text was updated successfully, but these errors were encountered: