Project

General

Profile

Actions

Bug #2333

closed

Signal: disconnecting a handler while it is executing is unsafe

Added by Davide Pesavento over 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Category:
Utils
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:

Description

It is not obvious that disconnecting the handler can deallocate it, thus leading to a use-after-free crash. It is even less obvious when the handler is a lambda, because wrapping it into a std::function creates a copy, therefore the copy will be deallocated regardless of the lifetime of the original lambda closure. This effectively means that lambdas cannot be used as handlers if they need to disconnect themselves.

Possible solution:

In Signal<>::disconnect, if m_isExecuting is true, do not call m_slots.erase. In Signal<>::operator() delete line 198 and, after the handler invocation, add:

if (m_currentSlot == m_slots.end())
  it = m_slots.erase(it);
else
  ++it;

This should keep the closure alive until after the handler has finished executing.


Related issues 2 (0 open2 closed)

Related to ndn-cxx - Bug #2302: UtilSignal/DisconnectSelfInHandler segfaultClosedJunxiao Shi

Actions
Related to ndn-cxx - Bug #2523: UtilSignal/DisconnectSelfInHandler use-after-freeClosedJunxiao Shi

Actions
Actions

Also available in: Atom PDF