On 2/2/21 2:29 PM, David Malcolm wrote:
On Tue, 2021-02-02 at 12:57 -0700, Martin Sebor via Gcc-patches wrote:
The strlen pass initializes its pointer_query member object with
a cache consisting of a couple of vec's. Because vec doesn't
implement RAII its memory must be explicitly released to avoid
memory leaks. The attached patch adds a dtor to
the strlen_dom_walker to do that.
Tested on x86_64-linux and by verifying that the cache leaks are
gone by compiling gcc.dg/Wstringop-overflow*.c tests under Valgrind.
I'll plan to commit this change as "obvious" tomorrow unless there
are suggestions for changes.
Why not make the vecs within struct pointer_query::cache_type's be
auto_vecs? Then presumably the autogenerated dtor for
pointer_query::cache_type would clean things up, as called from the
autogenerated dtor for strlen_dom_walker, when cleaning up the
var_cache field?
Or am I missing something? (sorry, I'm not familiar with this code)
Dave
It would work as long as the cache isn't copied or assigned anywhere.
I don't think it is either, and GCC compiles and no C tests fail, so
it should be okay.
But I'm leery of using auto_vec as a class member because of pr90904.
Looks like auto_vec now has a move ctor and move assignment but still
no safe copy ctor or assignment. The cache copy ctor and assignment
operator could be deleted to avoid accidental copies, but at that
point it starts to become more involved than just flushing the cache.
If you or someone else has a preference for using auto_vec despite
this I'll change it. Otherwise I'd just as soon leave it as is.
Martin
Martin
PS Valgrind shows a fair number of leaks even with the patch but
none of them due to the pointer_query cache.
