[clang static analyzer] Crash in printReferrer(const clang::ento::MemRegion*): Assertion `false && "Unexpected referrer region type."' failed. #107852
Comments
github-actions
bot
added
the
clang
shafik
added
needs-reduction
EugeneZelenko
added
clang:static analyzer
crash
|
@llvm/issue-subscribers-clang-static-analyzer Author: Tianxing He (tianxinghe)
commit 3e47883 (HEAD -> main, origin/main, origin/HEAD)
Author: Giulio Eulisse <10544+ktf@users.noreply.github.com>
Date: Thu Sep 5 10:16:51 2024 +0200
clang: /home/htx/Documents/llvm19/llvm-project/clang/lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:341: std::optional<std::__cxx11::basic_string<char> > printReferrer(const clang::ento::MemRegion*): Assertion `false && "Unexpected referrer region type."' failed.
|
|
I'll have a look tomorrow. |
|
I am trying to minimize it and will put it up tomorrow. （may be 12 hours later）
…---Original---
From: "Balazs ***@***.***>
Date: Tue, Sep 10, 2024 00:56 AM
To: ***@***.***>;
Cc: "Tianxing ***@***.******@***.***>;
Subject: Re: [llvm/llvm-project] [clang static analyzer] Crash inprintReferrer(const clang::ento::MemRegion*): Assertion `false && "Unexpectedreferrer region type."' failed. (Issue #107852)
I'll have a look tomorrow.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
command : clang --analyze Meanwhile, in version 18.1.0, when executing -- analyze, the null pointer dereference bug can be correctly detected: But when performing the dereference check alone, the bug cannot be detected normally minimal version: |
I would like to inquire about a few things: Will the analyzer stop checking if there are too many variables related to input values? |
|
Hi @tianxinghe I confirm that I could reproduce the crash you reported. I'll look into it be cause it crashes on the as I introduced the failing assertion.
Could you, please, reformulate your question? I did not understand what "too many variables related to input values" means.
Clang Static Analyzer currently ignores floating-point values.
AFAIK, the analyzer can work with a union as long as you access the same field. Once you access a different field, it forgets all it knows about the union. |
Fixes llvm#107852 Make it explicit that the checker skips alloca regions to avoid the risc of producing false positives for code that has advnaced memory management. StackAddrEscapeChecker already used this strategy when it comes to malloc'ed regions, so this change relaxes the assertion and explicitly silents the issues related to memory regions generated with alloca.
Hi! @necto
I would like to know if there is code like this in the source code: Will the checker stop checking? Thank you very much for your help and answers! |
I did not understand the part about "not vice versa". In any case, I think this discussion belongs to #108520
No, it will not stop checking, but it does not model SIMD vectors appropriately leading to both false negatives and false positives. typedef int vec1 __attribute__((__vector_size__(8)));
template<class T>
void clang_analyzer_dump(T);
void top() {
vec1 v1 = (vec1){1, 2};
clang_analyzer_dump(v1[0]); // 1 (correct)
clang_analyzer_dump(v1[1]); // 1 (incorrect)
v1[0] = 8;
clang_analyzer_dump(v1[0]); // 8 (correct)
clang_analyzer_dump(v1[1]); // 1 (incorrect)
}
int false_negative() {
vec1 v1 = (vec1){1, 0};
return 1 / v1[1]; // FN
}
int false_positive() {
vec1 v1 = (vec1){0, 1};
return 1 / v1[1]; // FP
} |
I totally understand. Very good example. thx！ |
…ons (llvm#109655) Fixes llvm#107852 Make it explicit that the checker skips `alloca` regions to avoid the risk of producing false positives for code with advanced memory management. StackAddrEscapeChecker already used this strategy when it comes to malloc'ed regions, so this change relaxes the assertion and explicitly silents the issues related to memory regions generated with `alloca`.
…ons (llvm#109655) Fixes llvm#107852 Make it explicit that the checker skips `alloca` regions to avoid the risk of producing false positives for code with advanced memory management. StackAddrEscapeChecker already used this strategy when it comes to malloc'ed regions, so this change relaxes the assertion and explicitly silents the issues related to memory regions generated with `alloca`.
commit 3e47883 (HEAD -> main, origin/main, origin/HEAD)
Author: Giulio Eulisse 10544+ktf@users.noreply.github.com
Date: Thu Sep 5 10:16:51 2024 +0200
clang --analyzecode.zip
The text was updated successfully, but these errors were encountered: