Skip to content

Fixes couple of native memory leaks#1597

Closed
tonyredondo wants to merge 2 commits into
masterfrom
tony/native-leak-fix
Closed

Fixes couple of native memory leaks#1597
tonyredondo wants to merge 2 commits into
masterfrom
tony/native-leak-fix

Conversation

@tonyredondo

Copy link
Copy Markdown
Member

This PR is a continuation of #1596 handling a couple of possible memory leaks in the native library.

@DataDog/apm-dotnet

@tonyredondo tonyredondo self-assigned this Jul 12, 2021
@tonyredondo tonyredondo added the status:work-in-progress Actively worked on. If this is a PR, no review needed yet. WIP. label Jul 12, 2021

@gleocadie gleocadie left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

most of the deletion should be delete and not delete[].
Rule being:

  • Allocate using new, delete with delete
  • Allocate using new[] delete with delete[]

The mixup is considered as undefined behavior

Maybe someday, as a big refactoring moving to std::unique_ptr/std::shared_ptr (depending on the semantic) could be a better option.

if (find_res != modules.end())
{
auto moduleHandler = find_res->second;
delete[] moduleHandler;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shoudn't it be delete moduleHandler instead ?

this->module = nullptr;
if (this->functionInfo != nullptr)
{
delete[] this->functionInfo;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't it be delete this->functionInfo instead ?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's possible to use std::unique_ptr here instead.

this->handler = nullptr;
for (auto moduleMethod : methods)
{
delete[] moduleMethod.second;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should'nt it be delete moduleMethod.second instead?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for methods it's also possible to use std::unique_ptr

{
if (this->rejit_queue_ != nullptr)
{
delete[] this->rejit_queue_;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shoudn't it be delete this->rejit_queue_; instead?

}
if (this->rejit_queue_thread_ != nullptr)
{
delete[] this->rejit_queue_thread_;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't it bedelete this->rejit_queue_thread_; instead ?

if (rejit_handler != nullptr)
{
rejit_handler->Shutdown();
delete[] rejit_handler;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should'nt it be delete rejit_handler; instead ?

{
if (calltargetTokens != nullptr)
{
delete[] calltargetTokens;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't it be delete calltargetTokens instead ?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in this case you can go for a std::unique_ptr.


hr = rewriter.Export();

delete[] newEHClauses;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could be risky no? you pass its pointer to the rewriter and ends it lifecyle before the rewriter lifecyle.
Couldn't you use std::unique_ptr instead ? (and passing the pointer to the rewriter using the .get method )?

@tonyredondo

Copy link
Copy Markdown
Member Author

most of the deletion should be delete and not delete[].
Rule being:

  • Allocate using new, delete with delete
  • Allocate using new[] delete with delete[]

The mixup is considered as undefined behavior

Maybe someday, as a big refactoring moving to std::unique_ptr/std::shared_ptr (depending on the semantic) could be a better option.

Yes is a WIP, I had to go out before completing this. That’s why the WIP label and the Draft 😊

this->rejit_queue_ = new BlockingQueue<RejitItem>();
this->rejit_queue_thread_ = new std::thread(enqueue_thread, this);
}
~RejitHandler()

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for both, it's possible to use std::unique_ptr instead

@gleocadie

Copy link
Copy Markdown
Collaborator

I tested a bit and overall, you can replace every raw pointers by a std::unique_ptr ;)

@tonyredondo

Copy link
Copy Markdown
Member Author

Superseeded by #1600

@tonyredondo tonyredondo deleted the tony/native-leak-fix branch December 28, 2022 19:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status:work-in-progress Actively worked on. If this is a PR, no review needed yet. WIP.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants