Closed
Bug 1374702
Opened 7 years ago
Closed 7 years ago
Crash in js::XDRState<T>::codeUint32
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla56
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox54 | --- | unaffected |
firefox55 | --- | fixed |
firefox56 | --- | fixed |
People
(Reporter: philipp, Assigned: kmag)
References
Details
(Keywords: crash, regression)
Crash Data
This bug was filed from the Socorro interface and is
report bp-cd4b97b8-bb5e-450c-84fb-4b4960170620.
=============================================================
Crashing Thread (8)
Frame Module Signature Source
0 xul.dll js::XDRState<1>::codeUint32(unsigned int*) js/src/vm/Xdr.h:251
1 xul.dll js::XDRScript<1>(js::XDRState<1>*, JS::Handle<js::Scope*>, JS::Handle<js::ScriptSourceObject*>, JS::Handle<JSFunction*>, JS::MutableHandle<JSScript*>) js/src/jsscript.cpp:381
2 xul.dll js::AtomizeChars<unsigned char>(JSContext*, unsigned char const*, unsigned int, js::PinningBehavior) js/src/jsatom.cpp:499
3 xul.dll js::XDRInterpretedFunction<1>(js::XDRState<1>*, JS::Handle<js::Scope*>, JS::Handle<js::ScriptSourceObject*>, JS::MutableHandle<JSFunction*>) js/src/jsfun.cpp:668
4 xul.dll js::XDRScript<1>(js::XDRState<1>*, JS::Handle<js::Scope*>, JS::Handle<js::ScriptSourceObject*>, JS::Handle<JSFunction*>, JS::MutableHandle<JSScript*>) js/src/jsscript.cpp:870
5 mozglue.dll je_malloc memory/mozjemalloc/mozjemalloc.cpp:4816
early data from the 55.0b staged rollout would suggest that this crash signature is increasing in frequency in the 55 cycle. so far all reports are from windows users with a 32bit version of the browser.
currently the signature is accounting for ~1% of browser crashes in 55.0b2
Comment 1•7 years ago
|
||
:nbp, could you investigate please ?
Crash Signature: [@ js::XDRState<T>::codeUint32] → [@ js::XDRState<T>::codeUint32]
[@ memcpy | js::XDRState<T>::codeBytes ]
Flags: needinfo?(nicolas.b.pierron)
Comment 2•7 years ago
|
||
First of all this stack is complete garbage: je_malloc should never call any XDR function at any time.
All these issues are decoding issues, which makes me thing that this is more likely to be an issue in the code which uses XDR instead of XDR it-self.
I guess I can toggle the read function to use a MOZ_RELEASE_ASSERT, but this would not be ideal.
Or we can store the expected size, as part of the XDR buffer, and fail eagerly before in case of obvious error.
https://crash-stats.mozilla.com/report/index/d820118c-e9d1-4f04-abb3-28a4e0170622
https://crash-stats.mozilla.com/report/index/0c35374c-ecc6-413e-8d69-f62f30170622
Comment 3•7 years ago
|
||
This might be This might be a duplicate of Bug 1373934.
Flags: needinfo?(nicolas.b.pierron) → needinfo?(kmaglione+bmo)
Reporter | ||
Updated•7 years ago
|
Crash Signature: [@ js::XDRState<T>::codeUint32]
[@ memcpy | js::XDRState<T>::codeBytes ] → [@ js::XDRState<T>::codeUint32]
[@ memcpy | js::XDRState<T>::codeBytes ]
[@ js::XDRState<T>::codeUint8]
Comment 4•7 years ago
|
||
Kris, any luck finding a workaround for this crash?
Comment 5•7 years ago
|
||
Looks fixed with the changes from bug 1382329.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(kmaglione+bmo)
Resolution: --- → FIXED
Updated•7 years ago
|
Assignee: nobody → kmaglione+bmo
status-firefox54:
--- → unaffected
status-firefox-esr52:
--- → unaffected
Depends on: 1382329
Target Milestone: --- → mozilla56
You need to log in
before you can comment on or make changes to this bug.
Description
•