This is an archive of the discontinued LLVM Phabricator instance.

[clang][Interp] Avoid leaking init maps of local primitive arrays
AbandonedPublic

Authored by tbaeder on Nov 18 2022, 2:39 AM.

Details

Summary

This shows up when the interpretation is interrupted, in this case because we're reading an uninitialized value, and so we don't get to the destroy instruction for the scope.

This adds a destroyAll() that calls deallocates all the local variables of all the scopes in the function. This works, but I was wondering if it should instead be a cleanupLeftovers() that's only used by the caller _if_ the interpretation wasn't successful.

Diff Detail

Event Timeline

tbaeder created this revision.Nov 18 2022, 2:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 18 2022, 2:39 AM
tbaeder requested review of this revision.Nov 18 2022, 2:39 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 18 2022, 2:39 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
tbaeder updated this revision to Diff 478598.Nov 29 2022, 7:53 AM

This is REALLY making me concerned again about ownership semantics in the interpreter. I don't have any real concerns with this patch-as-is, but I DO have concerns with the architecture that makes something like this necessary.

This looks good to me but I am wondering how "interpretation is interrupted" can happen.

It's interrupted whenever one of the emitXXX() functions returns false, or when one of the function in Interp.h returns false, e.g. when trying to read from a null pointer.

Generally LGTM though I had a suggestion that might help some of Erich's concerns. FWIW, I share his concerns about memory ownership in the interpreter becoming convoluted

clang/lib/AST/Interp/InterpFrame.h
51–53

Rather than allow anyone with access to the function to call it, would it make sense to put the functionality directly in the destructor? It's not a huge amount of code, and it reduces the cognitive overhead of figuring out who can destroy what.

tbaeder abandoned this revision.Mar 15 2023, 9:32 AM

Abandoning this since the approach is not feasible anymore with https://reviews.llvm.org/D145545