You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, if I understand this code correctly, here’s what I think happens:
Line 222 creates a pointer to a new Baton.
Line 230 stores a void pointer in the req.data property of the new Baton (which happens to be a pointer to itself)
Line 237 passes the reference to the new Baton’s req property to uv_queue_work.
After the noop_work_func completes, the AsyncMemwatchAfter callback will execute.
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
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.
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.
The text was updated successfully, but these errors were encountered: