There are multiple defects in NetworkWorker and the related parts
since the C++ rewrite. 1) NetworkService holds a reference to
NetworkWorker and never releases it. It has to wait until the cycle
collector comes up to resolve their ownership loop and free
NetworkWorker manually. However 2) nsINetworkWorker::shutdown is
never called, and that leaves everything living till the end,
inclusive of that gNetdConsumer in Netd.cpp. 3) when GC comes to free
NetworkWorker, it calls its parent destructor ~NetConsumer(), which
in turn calls ~RefCounted<NetdConsumer>(). Having a valid
gNetdConsumer in Netd.cpp follows its refCnt is not zero and this
triggers an assertion in ~RefCounted<NetdConsumer>().
So, some obvious treatments here. A) NetworkService should call
nsINetworkWorker::shutdown upon receiving a shutdown observer event
and release the reference to NetworkWorker. B) NetworkWorker should
never be double ref-counted. Move NetdConsumer implementation into a
separated class.
This patch was mostly generated with the following command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e '/WrapObject(JSContext/ {; N; s/\(WrapObject(JSContext *\* *a\{0,1\}[Cc]x\),\n\{0,1\} *JS::Handle<JSObject\*> a\{0,1\}[sS]cope/\1/ ; }' -i ""
and then reverting the changes that made to
dom/bindings/BindingUtils.h, since those WrapObject methods are not
the ones we're trying to change here, plus a bunch of manual fixups
for cases that this command did not catch (including all the callsites
of WrapObject()).
This patch was mostly generated with this command:
find . -name "*.h" -o -name "*.cpp" | xargs sed -e 's/Binding::Wrap(aCx, aScope, this/Binding::Wrap(aCx, this/' -e 's/Binding_workers::Wrap(aCx, aScope, this/Binding_workers::Wrap(aCx, this/' -e 's/Binding::Wrap(cx, scope, this/Binding::Wrap(cx, this/' -i ""
plus a few manual fixes to dom/bindings/Codegen.py, js/xpconnect/src/event_impl_gen.py, and a few C++ files that were not caught in the search-and-replace above.
nsIRILDataCallback has been abused in RadioInterfaceLayer.js and is
becoming an RIL internal utility. Besides, nsIRILDataCallback has
also racing problem as described in bug 976897. We should really use
NetworkManager observer events to replace the notification mechanism
here.