-
Notifications
You must be signed in to change notification settings - Fork 11.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
clang crash with HWASan after D159172 #66934
Labels
compiler-rt:hwasan
Hardware-assisted address sanitizer
Comments
thurstond
added a commit
to thurstond/llvm-project
that referenced
this issue
Sep 20, 2023
…tized HWAddressSanitizerPass::run sanitizes functions one by one. The sanitization of each function - which may split blocks via insertShadowTagCheck - may result in some cached analyses are invalid. This matters because sanitizeFunction(F', FAM) may indirectly call the global stack safety analysis, hence we need to make sure the analyses of F are up to date. Bug report: llvm#66934
We should probably also check whether we can teach the StackSafetyAnalysis not to revisit every function in a module for every function we sanitize. With your fix we will have quadratic number of dominator tree calculations for every module. |
thurstond
added a commit
to thurstond/llvm-project
that referenced
this issue
Sep 21, 2023
This patch incrementally updates the DominatorTreeAnalysis and LoopAnalysis whenever SplitBlockAndInsertIfThen is called, which fixes the following issue: Suppose we have two functions, F and G. HWAddressSanitizerPass::run will first sanitize F, which potentially makes the analyses of F out of date. When G is then sanitized, it may call the global stack safety analysis, which can crash if the analysis of F is stale. Additionally, since the DominatorTreeAnalysis and LoopAnalysis are now incrementally updated, they do not need to be abandoned at the end of the pass. Bug report: llvm#66934
thurstond
added a commit
to thurstond/llvm-project
that referenced
this issue
Sep 21, 2023
This patch incrementally updates the DominatorTreeAnalysis and LoopAnalysis whenever SplitBlockAndInsertIfThen is called, which fixes the following issue: Suppose we have two functions, F and G. HWAddressSanitizerPass::run will first sanitize F, which potentially makes the analyses of F out of date. When G is then sanitized, it may call the global stack safety analysis, which can crash if the analysis of F is stale. Additionally, since the DominatorTreeAnalysis and LoopAnalysis are now incrementally updated, they do not need to be abandoned at the end of the pass. Bug report: llvm#66934
thurstond
added a commit
to thurstond/llvm-project
that referenced
this issue
Sep 21, 2023
…ntally This patch incrementally updates the DominatorTreeAnalysis, PostDominatorTreeAnalysis and LoopAnalysis whenever SplitBlockAndInsertIfThen is called, which fixes the following issue: Suppose we have two functions, F and G. HWAddressSanitizerPass::run will first sanitize F, which potentially makes the analyses of F out of date. When G is then sanitized, it may call the global stack safety analysis, which can crash if the analysis of F is stale. Additionally, since the DominatorTreeAnalysis, PostDominatorTreeAnalysis and LoopAnalysis are now incrementally updated, they do not need to be abandoned at the end of the pass. Bug report: llvm#66934
thurstond
added a commit
to thurstond/llvm-project
that referenced
this issue
Sep 26, 2023
…ntally This patch incrementally updates the DominatorTreeAnalysis, PostDominatorTreeAnalysis and LoopAnalysis whenever SplitBlockAndInsertIfThen is called, which fixes the following issue: Suppose we have two functions, F and G. HWAddressSanitizerPass::run will first sanitize F, which potentially makes the analyses of F out of date. When G is then sanitized, it may call the global stack safety analysis, which can crash if the analysis of F is stale. Additionally, since the DominatorTreeAnalysis, PostDominatorTreeAnalysis and LoopAnalysis are now incrementally updated, they do not need to be abandoned at the end of the pass. Bug report: llvm#66934
thurstond
added a commit
that referenced
this issue
Sep 28, 2023
…ntally (#66935) HWAddressSanitizerPass::run sanitizes functions one by one. The sanitization of each function - which may split blocks via insertShadowTagCheck - may result in some cached analyses are invalid. This matters because sanitizeFunction(F', FAM) may indirectly call the global stack safety analysis, hence we need to make sure the analyses of F are up to date. Bug report: #66934
legrosbuffle
pushed a commit
to legrosbuffle/llvm-project
that referenced
this issue
Sep 29, 2023
…ntally (llvm#66935) HWAddressSanitizerPass::run sanitizes functions one by one. The sanitization of each function - which may split blocks via insertShadowTagCheck - may result in some cached analyses are invalid. This matters because sanitizeFunction(F', FAM) may indirectly call the global stack safety analysis, hence we need to make sure the analyses of F are up to date. Bug report: llvm#66934
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
N.B. I think I have a fix/workaround for this. This bug report is largely for recordkeeping, instead of dumping all the details in the git commit message.
Reproducer
clang tip-of-tree (9/20/23) crashes with:
Backtrace
Theory
This first started happening after "[HWASAN] Inline fast pass of instrumentMemAccessOutline" (https://reviews.llvm.org/D159172) landed. Some of the blocks end up being split by insertShadowTagCheck, which results in some cached analyses becoming invalid. Per the backtrace above, HWASan relies on a global stack safety analysis, which may use some stale analysis results, leading to the crash.
Tentative fix
The tentative fix (pull request coming very soon) is to invalidate the DominatorTreeAnalysis after each function is sanitized.
The text was updated successfully, but these errors were encountered: