Open
Bug 1927663
Opened 9 days ago
Updated 1 hour ago
MOZ_RELEASE_ASSERT(disabledHugeMemory) when setting javascript.options.wasm_disable_huge_memory=true
Categories
(Core :: JavaScript: WebAssembly, defect, P3)
Core
JavaScript: WebAssembly
Tracking
()
NEW
People
(Reporter: glandium, Assigned: rhunt)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Crash report on a nightly: https://crash-stats.mozilla.org/report/index/b2299b52-87ca-4fb5-a176-41cc90241029
STR:
- open about:config
- add a javascript.options.wasm_disable_huge_memory boolean pref and set it to true
- restart Firefox
Result:
- crash on startup. Can't be fixed until the pref is removed by editing the prefs.js file manually.
Comment 1•8 days ago
|
||
Hey, this seems... maybe up your alley?
Blocks: sm-defects-crashes
Severity: -- → S3
Component: JavaScript Engine → JavaScript: WebAssembly
Flags: needinfo?(rhunt)
Priority: -- → P1
Updated•8 days ago
|
Priority: P1 → P3
Assignee | ||
Comment 3•8 days ago
|
||
The old system required wasm::DisableHugeMemory() to be called
before anyone calls wasm::HugeMemoryEnabled(), and enforced that with
some runtime checks.
We had a bug where GetOptimizedBuildEncodingId() (which queries the
huge memory flag) would be called by Gecko before we read the pref.
This commit refactors this code to use a JS::Pref instead which is
always set before JS_Init() is invoked. This ensures that it is
never changed after we've observed the value and can drop all the
fancy runtime checking.
Pushed by rhunt@eqrion.net:
https://hg.mozilla.org/integration/autoland/rev/14d075fe7eea
wasm: Refactor handling of 'disable_huge_memory'. r=bvisness
You need to log in
before you can comment on or make changes to this bug.
Description
•