Bug #10425
closed
I am working on this bug.
- 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.
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?
- Backport set to dumpling,firefly
- Status changed from In Progress to 7
- Status changed from 7 to Pending Backport
- Backport changed from dumpling,firefly to firefly
1b26672 librados: fix resources leakage in RadosClient::connect(). (in firefly),
- Status changed from Pending Backport to Resolved
Also available in: Atom
PDF