On Fri, Aug 14, 2020 at 12:25:25PM -0400, Jeff King wrote: > On Fri, Aug 14, 2020 at 12:13:28PM -0400, Jeff King wrote: > > > Based on the discussion over in [1], I wondered how close we were to > > being able to run some test scripts with a leak-checker like LSan not > > complaining. The answer is...not close. > > > > I picked t5526 more or less at random (it was the first failure when I > > did a parallel "make test") to see what it would take to get it passing. > > After much effort...I have t5526.1, the setup test, running clean. :) > > For reference, here are the UNLEAK() calls I had to add to silence the > false positives. Some of these are kind of sketchy. For example, > declaring that wt_status_collect_changes_index() is allowed to leak is a > bit low-level for my tastes (in general it's probably only called once > per program, but it's getting quite far from the bottom of the stack). > But there's actually no convenient way to free the various bits of a > rev_info, so marking it with UNLEAK() is an expedient hack. And by the way, having gone through this exercise, I'm re-convinced that UNLEAK() is reasonable to keep. A lot of these cases would have been very awkward with free(). Not insurmountable, but cases where a variable is sometimes-allocated and sometimes-not get rather tricky. -Peff
