================
@@ -297,20 +314,29 @@ std::optional<std::string> printReferrer(const MemRegion
*Referrer) {
return "global";
assert(isa<StackSpaceRegion>(Space));
return "stack";
- }(Referrer->getMemorySpace());
-
- // We should really only have VarRegions here.
- // Anything else is really surprising, and we should get notified if such
- // ever happens.
- const auto *ReferrerVar = dyn_cast<VarRegion>(Referrer);
- if (!ReferrerVar) {
- assert(false && "We should have a VarRegion here");
- return std::nullopt; // Defensively skip this one.
+ }(getStackOrGlobalSpaceRegion(Referrer));
+
+ while (!Referrer->canPrintPretty()) {
+ if (const auto *SymReg = dyn_cast<SymbolicRegion>(Referrer)) {
+ Referrer = SymReg->getSymbol()->getOriginRegion()->getBaseRegion();
----------------
NagyDonat wrote:
Be careful with `getOriginRegion()`, it will return null if the symbol is not a
`SymbolRegionValue` or a `SymbolDerived` (e.g. a `SymbolConjured` returned by
an opaque function call)!
Even when `getOriginRegion()` returns a non-null region, that region is only
tangentially related to the symbol that was once stored in it. For example in a
function like
```cpp
void leaker(int **arg) {
int local;
*arg = local;
}
void foo(int *arg) {
int *original_arg = arg;
arg = tweak(arg);
leaker(&original_arg);
}
```
the bug report would (probably) look like _"local variable 'local' is still
referred to by the stack variable 'arg'"_ despite that the leaked reference is
held through `original_arg` and not the new value of `arg`. Consider adding a
testcase which shows this limitation.
I know that `getOriginRegion()` is currently the best tool for producing an
user-readable description in situations like this, but it is fundamentally
inaccurate, so I hope that eventually we could replace it with some more
accurate solution (e.g. a mapping or function which maps a symbol to a variable
which is currently storing that symbol).
https://github.com/llvm/llvm-project/pull/105653
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
