Bug #10425
closedRadosClient::connect leaks Objecter if called twice
0%
Description
http://workbench.dachary.org/ceph/ceph/blob/giant/src/librados/RadosClient.cc#L226
If RadosClient::connect is called a second time (maybe after fixing an error condition), the Objecter allocated by the first call will be leaked.
Files
Updated by Loïc Dachary over 9 years ago
- Status changed from 12 to In Progress
- Assignee set to Loïc Dachary
Cool, thanks. I assign it to myself to track this, let me know if you need any help.
Updated by Radoslaw Zarzynski over 9 years ago
I am attaching the first proposal of patch for your review.
Besides rectifying the Objecter leak, two additional things have been done in the body of RadosClient::connect method:- Switch from throwing variant of “new” to the non-throwing one. I think that handling memory allocation problems via std::bad_alloc exception was unintentional behavior, especially due to the usage of ENOMEM return code across the whole method. It might lead to stuck in CONNECTING state in some circumstances.
- Leak of Messenger instance. The issue is very similar to the main problem so I am proposing to fix it together.
Could you please tell me about guard (objecter != NULL) on RadosClient::wait_for_osdmap method? Does the check need to base on assumption about objecter? Maybe the explicit state verification (like in other methods of the class) should be performed?
Updated by Radoslaw Zarzynski about 9 years ago
Link to pull request: https://github.com/ceph/ceph/pull/3513
Updated by Loïc Dachary about 9 years ago
Updated by Loïc Dachary about 9 years ago
- Status changed from 7 to Pending Backport
Updated by Loïc Dachary about 9 years ago
- Backport changed from dumpling,firefly to firefly
dumpling is end of life
Updated by Loïc Dachary about 9 years ago
1b26672 librados: fix resources leakage in RadosClient::connect(). (in firefly),
Updated by Loïc Dachary about 9 years ago
- Status changed from Pending Backport to Resolved