922430 - memory allocated by nsWrapperCache goes unreported

Status: NEW

(Core :: XPConnect, defect)

Description

[Nathan Froyd [:froydnj]]

Unreported: ~722 blocks in stack trace record 12 of 8,620
 ~2,955,146 bytes (~2,955,146 requested / ~0 slop)
 0.33% of the heap (8.70% cumulative);  1.31% of unreported (34.15% cumulative)
 Allocated at
   replace_malloc (/home/froydnj/src/mozilla-central-official/memory/replace/dmd/DMD.cpp:1227) 0x7fdcb0f20f44
   moz_xmalloc (/home/froydnj/src/mozilla-central-official/memory/mozalloc/mozalloc.cpp:55) 0x7fdcb0f12121
   operator new (/opt/build/froydnj/build-mc/content/base/src/../../../dist/include/mozilla/mozalloc.h:201) 0x7fdcad14b02c
   nsWrapperCache::HasWrapperFlag(unsigned int) const (/home/froydnj/src/mozilla-central-official/dom/base/nsWrapperCache.h:271) 0x7fdcad9dacc4
   genericGetter (/opt/build/froydnj/build-mc/dom/bindings/NodeBinding.cpp:1254) 0x7fdcad9e5479
   CallJSNative (/home/froydnj/src/mozilla-central-official/js/src/jscntxtinlines.h:218) 0x7fdcae140653
   js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (/home/froydnj/src/mozilla-central-official/js/src/vm/Interpreter.cpp:512) 0x7fdcae1425cd
   js::InvokeGetterOrSetter(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>) (/home/froydnj/src/mozilla-central-official/js/src/vm/Interpreter.cpp:584) 0x7fdcae1426fd
   js::BaseProxyHandler::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<long>, JS::MutableHandle<JS::Value>) (/home/froydnj/src/mozilla-central-official/js/src/jsproxy.cpp:140) 0x7fdcae2aedc1
   js::Proxy::get(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<long>, JS::MutableHandle<JS::Value>) (/home/froydnj/src/mozilla-central-official/js/src/jsproxy.cpp:2476) 0x7fdcae2b3ca2
   DoGetPropFallback (/home/froydnj/src/mozilla-central-official/js/src/jit/BaselineIC.cpp:5969) 0x7fdcae31df80
   ??? 0x7fdc9f6505dc

Comment 1

[Boris Zbarsky [:bzbarsky]]

There's no way HasWrapperFlag is calling operator new.

Furthermore, genericGetter at that point is not calling HasWrapperFlag.

As in, that entire part of the stack is bogus-looking....  CallJSNative calling genericGetter makes sense, but the indirect call from there seems to be totally misreported stack-wise here.  :(

Comment 2

[Nathan Froyd [:froydnj]]

(In reply to Boris Zbarsky [:bz] from comment #1)
> There's no way HasWrapperFlag is calling operator new.
> 
> Furthermore, genericGetter at that point is not calling HasWrapperFlag.
> 
> As in, that entire part of the stack is bogus-looking....  CallJSNative
> calling genericGetter makes sense, but the indirect call from there seems to
> be totally misreported stack-wise here.  :(

Hm, DMD does seem to be reporting bogus information here, or at least addr2line is reporting bogus information, or the debug information is bogus here, or some combination of the above.  Manual examination of DMD's output and disassembly suggests that:

NodeBinding::get_childNodes(JSContext*, JS::Handle<JSObject*>, nsINode*, JSJitGetterCallArgs)

is actually the function in question instead of HasWrapperFlag.

Comment 3

[Boris Zbarsky [:bzbarsky]]

OK.  So looking at get_childNodes it has the following things it calls:

1)  self->ChildNodes().  This is not inlined, but can in fact allocate a nodelist via
    operator new, and can allocate slots.  Neither is reported, like everything else in
    DOM slots.  See nsINode::SizeOfExcludingThis.
2)  WrapNewBindingObject.  This _is_ inlined, but makes no direct operator new calls.

I suspect the allocation here is one of the ones from ChildNodes()....