Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource leak in memwatch.cc #4

Open
Fotiman opened this issue Dec 4, 2019 · 1 comment
Open

Resource leak in memwatch.cc #4

Fotiman opened this issue Dec 4, 2019 · 1 comment

Comments

@Fotiman
Copy link

Fotiman commented Dec 4, 2019

The Coverity Security Scan software reports a resource leak on line 238. The actual message states:

leaked_storage: Variable baton going out of scope leaks the storage it points to.

image

@Fotiman
Copy link
Author

Fotiman commented Dec 4, 2019

However, if I understand this code correctly, here’s what I think happens:

  1. Line 222 creates a pointer to a new Baton.
  2. Line 230 stores a void pointer in the req.data property of the new Baton (which happens to be a pointer to itself)
  3. Line 237 passes the reference to the new Baton’s req property to uv_queue_work.
  4. After the noop_work_func completes, the AsyncMemwatchAfter callback will execute.
  5. That method is passed the pointer to the req property of the new Baton. It then dereferences the data property (the pointer to the original new Baton) and assigns it to a new Baton pointer. This is now pointing at the address of the originally created new Baton from line 222
  6. At the end of that function it deletes the value that was being pointed to by pointer b.

So I think this means that there is no actual resource leak here, but that Coverity just has no way to detect it. I'm a bit rusty with C++ though, so hoping someone can verify that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant