This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Remove memoization from RunLoopAutoreleaseLeakChecker
ClosedPublic

Authored by george.karpenkov on Nov 26 2018, 3:11 PM.

Details

Summary

Memoization dose not seem to be necessary, as other statement visitors run just fine without it,
and in fact seems to be causing memory corruptions.
Just removing it instead of investigating the root cause.

rdar://45945002

Diff Detail

Repository
rC Clang

Event Timeline

NoQ added a comment.Nov 29 2018, 12:32 PM

Like, i mean, is it possible to obtain a test case for the memory corruption?

Like, i mean, is it possible to obtain a test case for the memory corruption?

I haven't reduced it, and it only runs under ASAN

NoQ added a comment.Nov 29 2018, 12:49 PM

So an ASAN buildbot will catch a regression. I think it's cool.

NoQ accepted this revision.Dec 10 2018, 5:11 PM

Let's commit without a test because of the urgency, and add the test soon.

This revision is now accepted and ready to land.Dec 10 2018, 5:11 PM
This revision was automatically updated to reflect the committed changes.
NoQ added a comment.Dec 11 2018, 12:12 PM

Hmm, i think i get it. Cached is a reference. Changing Memoization will invalidate references because DenseMap doesn't provide the respective guarantee.

Here's how the code should have looked:

~  77     Optional<TriBoolTy> Cached = Memoization[C];
~  78     if (!Cached) {
   79       Cached = seenBeforeRec(C, A, B, Memoization);
+  80       Memoization[C] = Cached;
+  81     }

@NoQ thanks, interesting! But I thought the underlying map is not actually modified while the reference is alive?

NoQ added a comment.Dec 11 2018, 12:22 PM

I think that it is modified, at least, when Memoization[C] is evaluated. The object needs to be created and put into the map in order to obtain a reference to it.

NoQ added a comment.Dec 11 2018, 12:23 PM

That is, it is modified within the recursive call.

NoQ added a comment.Dec 12 2018, 5:34 PM

Added a test in rC349000.