Closed Bug 1374702 Opened 7 years ago Closed 7 years ago

Crash in js::XDRState<T>::codeUint32

Categories

(Core :: JavaScript Engine, defect)

55 Branch
x86
Windows
defect
Not set
critical

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
: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)
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
This might be This might be a duplicate of Bug 1373934.
Flags: needinfo?(nicolas.b.pierron) → needinfo?(kmaglione+bmo)
Crash Signature: [@ js::XDRState<T>::codeUint32] [@ memcpy | js::XDRState<T>::codeBytes ] → [@ js::XDRState<T>::codeUint32] [@ memcpy | js::XDRState<T>::codeBytes ] [@ js::XDRState<T>::codeUint8]
Kris, any luck finding a workaround for this crash?
Looks fixed with the changes from bug 1382329.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(kmaglione+bmo)
Resolution: --- → FIXED
Assignee: nobody → kmaglione+bmo
Depends on: 1382329
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.