1549569 - [hazards] Cannot follow control flow through std::function<T>::_M_invoker()

Status: NEW

(Core :: JavaScript: GC, defect, P3)

Description

[Steve Fink [:sfink] [:s:]]

In attempting to remove the false positives resulting from fixing bug 1531951, I ran into the following stack:

void nsIGlobalObject::DisconnectEventTargetObjects()
void nsIGlobalObject::ForEachEventTargetObject(std::function<void(mozilla::DOMEventTargetHelper*, bool*)>*)>&) const
_Res std::function<_Res(_ArgTypes ...)>::operator()(_ArgTypes ...) const [with _Res = void; _ArgTypes = {mozilla::DOMEventTargetHelper*, bool*}]
const std::function<void(mozilla::DOMEventTargetHelper*, bool*)>._M_invoker(...)
arbitrary function pointer const std::function<void(mozilla::DOMEventTargetHelper*, bool*)>._M_invoker(...)

The analysis is unable to see that ForEachEventTargetObject will only call the lambda function passed to it, because std::function<T>::operator() calls through a function pointer.

This will probably just require a bunch of special-casing. At the time we're gathering possible callees of std::function<T>::operator(), we don't have the lambda in hand anymore. So I guess I'll have to do this at the ForEachEventTargetObject level? Kind of unfortunate. I did have a weird hack to "specialize" callee functions with the identity of statically-known callbacks, and generate new callgraph nodes based on those. I could maybe revive that as a more general mechanism for this?

Comment 1

[Steve Fink [:sfink] [:s:]]

cf bug 1398213