01:45:16 sefeng: your issue sounds different, because you were logging only your class and not also a subclass. 01:45:28 sefeng: I would guess that the assertion is actually an indication of the "leak" you are seeing. 01:45:54 sefeng: probably some element was previously allocated at that address, then the element was freed, but we didn't tell refcount logging, then we allocated a new thing there. 01:45:56 sefeng: so you hit the assert. 01:47:15 sefeng: one thing you could try doing is printing out the stack and address in the fragmentorelement dtor. 01:47:37 sefeng: then, when you hit this assert, look at what the dtor stack is for that address and try to figure out why we aren't calling the NS_LOG_RELEASE for it. 01:47:52 and look at what the most recent refcount log traffic is for that address. 01:48:44 You can log the stack by doing NS_ASSERTION(false, "some string"); and then running Firefox with 01:48:44 XPCOM_DEBUG_BREAK = stack 01:48:49 https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/XPCOM_DEBUG_BREAK 03:24:49 gandalf: What did I miss? 03:26:03 Mossop: smaug asked: 03:26:16 smaug> before I forget. in paolo's approach, when would we create the cache? 03:26:16 5:45 PM first run? 03:26:16 5:45 PM could we dump this ad-hoc cache to xul cache 03:26:16 5:51 PM https://searchfox.org/mozilla-central/rev/adec563403271e78d1a057259b3e17fe557dfd91/dom/xbl/nsXBLDocumentInfo.cpp#248-280 is possibly the simplest way to write 03:26:16 5:51 PM and https://searchfox.org/mozilla-central/rev/adec563403271e78d1a057259b3e17fe557dfd91/dom/xbl/nsXBLDocumentInfo.cpp#184-233 for reading 03:27:06 Yes that could work