Leak when system ESM is used
Categories
(Core :: XPConnect, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox104 | --- | fixed |
People
(Reporter: arai, Assigned: jonco)
References
Details
Attachments
(3 files)
Apply the attachment, and run test browser/components/pagedata/tests/browser/browser_pagedata_basic.js
test passes, but leak is detected.
0:13.40 GECKO(54974) WARNING: YOU ARE LEAKING THE WORLD (at least one JSRuntime and everything alive inside it, that is) AT JS_ShutDown TIME. FIX THIS!
0:13.40 GECKO(54974) [Parent 54974, Main Thread] ###!!! ASSERTION: 29 dynamic atom(s) with non-zero refcount: downloads-item-font-size-factor,protections-popup-trackersView,key_hideThisAppCmdMac,private-browsing-indicator,PanelUI-bookmarks,translate-notification-icon,manBookmarkKb,downloadsCmd_clearList,menu_printSetup,key_preferencesCmdMac,context-openlinkprivate,find-button,key_responsiveDesignMode,pageStyleMenu,extension-new-tab,downloadHoveringButton,desktop,key_inspector,Unmute,chromeclass-toolbar,...: 'nonZeroRefcountAtomsCount == 0', file /Users/arai/projects/mozilla-unified/xpcom/ds/nsAtomTable.cpp:443
Assignee | ||
Updated•3 years ago
|
Reporter | ||
Comment 1•3 years ago
|
||
possibly related failure
https://treeherder.mozilla.org/jobs?repo=try&group_state=expanded&revision=cd4cb9a330e83d5f008175e578bfbfaa286f1c76&selectedTaskRun=ObM-1uAIRoGVMCA2GbKWZQ.0
[task 2022-07-01T10:11:28.019Z] 10:11:28 INFO - GECKO(11722) | Hit MOZ_CRASH(mozilla::LinkedList<mozilla::dom::ContentParent>::~LinkedList() [T = mozilla::dom::ContentParent] has a buggy user: it should have removed all this list's elements before the list's destruction) at /builds/worker/workspace/obj-build/dist/include/mozilla/LinkedList.h:466
[task 2022-07-01T10:11:28.020Z] 10:11:28 INFO - GECKO(11722) | #01: mozilla::LinkedList<mozilla::dom::ContentParent>::~LinkedList() [mfbt/LinkedList.h:462]
[task 2022-07-01T10:11:28.020Z] 10:11:28 INFO - GECKO(11722) | #02: mozilla::UniquePtr<mozilla::LinkedList<mozilla::dom::ContentParent>, mozilla::DefaultDelete<mozilla::LinkedList<mozilla::dom::ContentParent> > >::reset(mozilla::LinkedList<mozilla::dom::ContentParent>*) [mfbt/UniquePtr.h:305]
[task 2022-07-01T10:11:28.022Z] 10:11:28 INFO - GECKO(11722) | #03: ??? [/lib/x86_64-linux-gnu/libc.so.6 + 0x430f1]
[task 2022-07-01T10:11:28.023Z] 10:11:28 INFO - GECKO(11722) | #04: ??? [/lib/x86_64-linux-gnu/libc.so.6 + 0x431ea]
[task 2022-07-01T10:11:28.023Z] 10:11:28 INFO - GECKO(11722) | #05: __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6 + 0x21b9e]
[task 2022-07-01T10:11:28.023Z] 10:11:28 INFO - GECKO(11722) | #06: ??? [/builds/worker/workspace/build/application/firefox/firefox + 0x44169]
[task 2022-07-01T10:11:28.024Z] 10:11:28 INFO - GECKO(11722) | #07: ??? (???:???)
Comment 2•3 years ago
|
||
Yes, that's another assertion that shows up when you leak.
Reporter | ||
Comment 3•3 years ago
|
||
This code in JSM case looks related
if (obj) {
if (JS_HasExtensibleLexicalEnvironment(obj)) {
JS::RootedObject lexicalEnv(mozilla::dom::RootingCx(),
JS_ExtensibleLexicalEnvironment(obj));
JS_SetAllNonReservedSlotsToUndefined(lexicalEnv);
}
JS_SetAllNonReservedSlotsToUndefined(obj);
the equivalent might be necessary for ESM
Reporter | ||
Comment 4•3 years ago
|
||
So far, clearing the module environment during mozJSModuleLoader::Unload
seems to solve the leak in the testcase.
Assignee | ||
Comment 5•3 years ago
|
||
(In reply to Tooru Fujisawa [:arai] from comment #4)
I feel that this shouldn't be necessary, but it's the equivalent of what mozJSModuleLoader already does for JSMs so let's take this to make ESM module loading work.
Assignee | ||
Comment 6•3 years ago
|
||
Comment 7•3 years ago
|
||
bugherder |
Description
•