Closed
Bug 1688711
Opened 5 years ago
Closed 5 years ago
Crash in [@ mozilla::dom::IOUtils::ReadSync]
Categories
(Toolkit Graveyard :: OS.File, defect, P2)
Tracking
(firefox-esr78 unaffected, firefox85 unaffected, firefox86 fixed, firefox87 fixed)
RESOLVED
FIXED
87 Branch
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox85 | --- | unaffected |
firefox86 | --- | fixed |
firefox87 | --- | fixed |
People
(Reporter: kbrosnan, Assigned: beth)
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
Crash report: https://crash-stats.mozilla.org/report/index/70d0d4fc-2e26-409d-a5df-a646a0210124
MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(mBuffer.get())
Top 10 frames of crashing thread:
0 libxul.so mozilla::dom::IOUtils::ReadSync dom/system/IOUtils.cpp:830
1 libxul.so mozilla::detail::ProxyFunctionRunnable<RefPtr<mozilla::MozPromise<mozilla::dom::IOUtils::JsBuffer, mozilla::dom::IOUtils::IOError, true> > mozilla::dom::IOUtils::RunOnBackgroundThread<mozilla::dom::IOUtils::JsBuffer, mozilla::dom::IOUtils::Read xpcom/threads/MozPromise.h:1630
2 libxul.so mozilla::TaskQueue::Runner::Run xpcom/threads/TaskQueue.cpp:158
3 libxul.so nsThreadPool::Run xpcom/threads/nsThreadPool.cpp:301
4 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1200
5 libxul.so NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:548
6 libxul.so mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:332
7 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:309
8 libxul.so nsThread::ThreadFunc xpcom/threads/nsThread.cpp:441
9 libnss3.so _pt_root nsprpub/pr/src/pthreads/ptthread.c:201
Reporter | ||
Comment 1•5 years ago
|
||
This seems to be spiking in Android nightlies
Assignee | ||
Updated•5 years ago
|
Assignee: nobody → brennie
Status: NEW → ASSIGNED
Assignee | ||
Updated•5 years ago
|
Severity: -- → S3
Priority: -- → P2
Assignee | ||
Comment 2•5 years ago
|
||
Pushed by brennie@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7ed7b5a9c6bc
Don't write to empty JsBuffer when reading compressed files r=emalysz
Comment 4•5 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
status-firefox87:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch
Updated•4 years ago
|
status-firefox85:
--- → unaffected
status-firefox86:
--- → affected
status-firefox-esr78:
--- → unaffected
Flags: needinfo?(brennie)
Flags: in-testsuite+
Assignee | ||
Comment 5•4 years ago
|
||
Comment on attachment 9200139 [details]
Bug 1688711 - Don't write to empty JsBuffer when reading compressed files r?emalysz
Beta/Release Uplift Approval Request
- User impact if declined: If we decline this, we will likely see a crash spike in 86 release once its merged.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky):
- String changes made/needed:
Flags: needinfo?(brennie)
Attachment #9200139 -
Flags: approval-mozilla-beta?
Comment 6•4 years ago
•
|
||
Comment on attachment 9200139 [details]
Bug 1688711 - Don't write to empty JsBuffer when reading compressed files r?emalysz
Approved for 86.0rc1 and Fenix 86.0b5.
Attachment #9200139 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 7•4 years ago
|
||
bugherder uplift |
Updated•2 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•