This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Fix RichManglingContext::FromCxxMethodName() leak
ClosedPublic

Authored by rupprecht on Apr 19 2021, 2:35 PM.

Details

Summary

RichManglingContext::FromCxxMethodName allocates a m_cxx_method_parser, but never deletes it.

This fixes a -DLLVM_USE_SANITIZER=Leaks failure.

Diff Detail

Event Timeline

rupprecht requested review of this revision.Apr 19 2021, 2:35 PM
rupprecht created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptApr 19 2021, 2:35 PM
shafik added a subscriber: shafik.Apr 19 2021, 4:03 PM
shafik added inline comments.
lldb/source/Core/RichManglingContext.cpp
24

This code is duplicated from ResetProvider(...) we should factor it out and call it from both places, so we if we ever change this code in the future we don't have to remember to fix both places.

rupprecht updated this revision to Diff 338665.Apr 19 2021, 4:15 PM
  • Refactor cleanup of m_cxx_method_parser
rupprecht marked an inline comment as done.Apr 19 2021, 4:16 PM
rupprecht updated this revision to Diff 338979.Apr 20 2021, 1:29 PM
  • Move comment about switch to the correct spot
teemperor accepted this revision.Apr 20 2021, 4:05 PM

LGTM, thanks for fixing this!

We don't really have a thread for keep track of what other leak sanitiser failures needs to be fixed, but I believe with this revision (+ the revisions that I have to land) the only leaks left are related to reproducers or Python.

This revision is now accepted and ready to land.Apr 20 2021, 4:05 PM
JDevlieghere added inline comments.Apr 20 2021, 4:10 PM
lldb/source/Core/RichManglingContext.cpp
23

Instead of managing memory by hand, can we use a unique_ptr<char[]> instead?

rupprecht added inline comments.Apr 20 2021, 6:20 PM
lldb/source/Core/RichManglingContext.cpp
23

The buffer here is created by malloc, and from a cursory reading of processIPDStrResult, can be passed to other methods that call realloc on it. It should be paired with free, not delete. You could put that in a unique_ptr<char, FreeDeleter>, but when you go down that road, I think it's probably simpler to leave as-is. (You'd also have to take care to always manually .release() it when updating it to the realloc'd value, because you don't want to delete the pre-realloc'd buffer).

(Note: this line is pulled from the original ~RichManglingContext() definition in the header. I didn't write it so I can't defend it that well :) )

Thank you for reforactoring into ResetCxxMethodParser.

lldb/source/Core/RichManglingContext.cpp
23

I didn't suggest this b/c it was clear it was a quick fix and it seemed a reach to ask for that in this fix.

JDevlieghere added inline comments.Apr 20 2021, 7:01 PM
lldb/source/Core/RichManglingContext.cpp
23

Thanks for the explanation! That does sound like a bit of overkill. If it's not already documented, would it be useful to leave that as a comment somewhere?

dblaikie added inline comments.
lldb/source/Core/RichManglingContext.cpp
23

(I think for this patch, makes sense not to try to address the ownership/allocation model because it is non-trivial, as you've mentioned - but longer term, it might be worth revisiting it at some point - as it has a non-trivial & not well enforced boundary in terms of the allocation scheme shared between RichManglingContext and ItaniumPartialDemangler. It'd be good if that boundary were more clear rather than requiring malloc'd memory to be passed in, and requiring the caller to free it - some kind of abstraction over the memory ownership would probably be good to have)

rupprecht updated this revision to Diff 339264.Apr 21 2021, 9:03 AM
rupprecht marked 4 inline comments as done.
  • Add comments about memory management for m_ipd_buf
rupprecht added inline comments.Apr 21 2021, 9:05 AM
lldb/source/Core/RichManglingContext.cpp
23

Added a comment to the header. Agree about the longer term fixes on the API boundaries -- D100800 is a leak fix for that API, so it's clearly an API with sharp edges.

This revision was landed with ongoing or failed builds.Apr 21 2021, 12:34 PM
This revision was automatically updated to reflect the committed changes.