Closed
Bug 1340117
Opened 7 years ago
Closed 7 years ago
Firefox crash when editing openstreetmap
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
FIXED
mozilla54
Tracking | Status | |
---|---|---|
firefox51 | --- | unaffected |
firefox52 | --- | unaffected |
firefox-esr52 | --- | unaffected |
firefox53 | --- | unaffected |
firefox54 | + | fixed |
People
(Reporter: sydney.gems, Assigned: mattwoodrow)
References
Details
(Keywords: crash, regression)
Crash Data
Attachments
(2 files)
173.21 KB,
text/plain
|
Details | |
42.21 KB,
patch
|
dvander
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0 Build ID: 20170215110151 Steps to reproduce: Go to openstreetmap Enter edit mode Navigate for a while Actual results: Firefox crashed
Reporter | ||
Updated•7 years ago
|
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
No crash reports in about:crashes?
Severity: normal → critical
Keywords: crash
Reporter | ||
Comment 2•7 years ago
|
||
Indeed, there is https://crash-stats.mozilla.com/report/index/1ce1eab5-7ec8-4142-bf9e-7c59a2170216
Crash Signature: [@ mozilla::ipc::FatalError | libxul.so@0xc76668 | mozilla::layers::PLayerTransactionParent::Read ]
Component: Activity Streams: General → Graphics: Layers
Product: Firefox → Core
Is the same crash reproducible with the current release of Firefox (51)?
Reporter | ||
Comment 4•7 years ago
|
||
No, it seems to work fine.
Could you try to narrow down a regression range with the tool mozregression. See http://mozilla.github.io/mozregression/ for details. Run the command "mozregression --good=51" then copy here the final pushlog from repo mozilla-inbound.
Flags: needinfo?(sydney.gems)
Keywords: regressionwindow-wanted
Updated•7 years ago
|
Status: UNCONFIRMED → NEW
Crash Signature: [@ mozilla::ipc::FatalError | libxul.so@0xc76668 | mozilla::layers::PLayerTransactionParent::Read ] → [@ mozilla::ipc::FatalError | libxul.so@0xc76668 | mozilla::layers::PLayerTransactionParent::Read ]
[@ mozilla::ipc::FatalError | libxul.so@0xc799b8 | mozilla::layers::PLayerTransactionParent::Read]
Ever confirmed: true
Comment 7•7 years ago
|
||
I'm able to re-create similar crash-stacks on linux on current nightly using http://graphalchemist.github.io/Alchemy/#/examples and clicking on the "Philosophers' Relatedness" example, which produces a very densely packed SVG graph with a lot of churn as the force-directed layout animates things all over the place. Prior to the crash, many log messages of the following variety are emitted: [GFX1-]: Failed 2 buffer db=0 dw=0 for -41, -9, 82, 25 [GFX1-]: Failed 2 buffer db=0 dw=0 for -24, -9, 64, 25 then (many again): [Child 21365] WARNING: Too many file descriptors for one message!: file /home/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_message_utils.h, line 452 [Child 21365] WARNING: Too many file descriptors for one message!: file /home/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_message_utils.h, line 452 then just the one: IPDL protocol error: Error deserializing 'sem' (CrossProcessSemaphoreHandle) member of 'CrossProcessSemaphoreDescriptor' Crashes: https://crash-stats.mozilla.com/report/index/7b27694b-fd65-46ec-9c6a-5040f2170220 https://crash-stats.mozilla.com/report/index/398f882f-7bbd-48dd-a60b-25f012170220 https://crash-stats.mozilla.com/report/index/b9ca2035-3480-4f63-a56d-4a9d52170220 https://crash-stats.mozilla.com/report/index/cc00706b-b03f-40cd-8537-4022d2170220
Andrew, can you run mozregression to narrow down a regression range in FF53 or 54?
Flags: needinfo?(bugmail)
Crash Signature: [@ mozilla::ipc::FatalError | libxul.so@0xc76668 | mozilla::layers::PLayerTransactionParent::Read ]
[@ mozilla::ipc::FatalError | libxul.so@0xc799b8 | mozilla::layers::PLayerTransactionParent::Read] → [@ mozilla::ipc::FatalError | libxul.so@0xc76668 | mozilla::layers::PLayerTransactionParent::Read ]
[@ mozilla::ipc::FatalError | libxul.so@0xc799b8 | mozilla::layers::PLayerTransactionParent::Read]
[@ mozilla::ipc::FatalError | libxul.so@0xc7a776 | moz…
Comment 9•7 years ago
|
||
regression-window |
Tested with Comment#7, I can reproduce the crash with ubuntu16.04 32bit on VMWare. Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bcda57aa0c3b291dcd5de5d7fd048af69dbdff4d&tochange=a19ac5da60828cdcf374e6798dc7e07b8b4c1b7d
status-firefox51:
--- → unaffected
status-firefox52:
--- → unaffected
status-firefox53:
--- → unaffected
status-firefox54:
--- → affected
Blocks: 1325227
tracking-firefox54:
--- → ?
Flags: needinfo?(sydney.gems)
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(bugmail)
Keywords: regressionwindow-wanted → regression
Comment 11•7 years ago
|
||
BTW, there are quite easy STR for possibly-the-same-issue in bug 1341807. (Just open a particular cleopatra profile, and resize your browser, and crash.)
Assignee | ||
Comment 12•7 years ago
|
||
The IPC code sets a limit on the maximum number of file descriptors that can be sent in a single message. As discussed on irc, this moves lock initialization into a separate message (that can be batched if necessary), and only persists the mapping until the next layer transaction to avoid needing to change the lifetime guarantees that are currently present.
Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Attachment #8841411 -
Flags: review?(dvander)
Comment on attachment 8841411 [details] [diff] [review] Share locks over IPC using a separate message Review of attachment 8841411 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/layers/ipc/ImageBridgeChild.cpp @@ +111,4 @@ > OpVector mOperations; > OpDestroyVector mDestroyedActors; > + nsTArray<ReadLockVector> mReadLocks; > + uint64_t mReadLockCount; s/Count/SequenceNumber/ would be better ::: gfx/layers/ipc/ShadowLayers.cpp @@ +79,5 @@ > mRotationChanged = true; > } > mTargetRotation = aRotation; > mTargetOrientation = aOrientation; > + mReadLockCount = 0; Ditto here.
Attachment #8841411 -
Flags: review?(dvander) → review+
Comment 14•7 years ago
|
||
Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/e7e495f38cf3 Batch ReadLock intializer into a separate IDPL message to avoid hitting the file descriptor limit. r=dvander
Comment 16•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/e7e495f38cf3
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Updated•7 years ago
|
status-firefox-esr52:
--- → unaffected
Updated•7 years ago
|
Flags: qe-verify+
Comment 17•7 years ago
|
||
I am still able to reproduce the crash with 54 beta 2 (20170424215451) using STR from comment 7, on Ubuntu 16.04 x64 LTS and Ubuntu 14.04 x86 LTS. With e10s disable I am not able to see the crash signature because I'm getting this error message: "Firefox had a problem and crashed. We’ll try to restore your tabs and windows when it restarts. Unfortunately the crash reporter is unable to submit a crash report. Details: The application did not leave a crash dump file." If I enable e10s, Firefox submits the crash report with the following crash signature: - https://crash-stats.mozilla.com/report/index/d1bb054a-bdf1-4d1c-87f1-c174c0170425 What do you think about this, Matt?
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 18•7 years ago
|
||
Unfortunately that crash report appears to be corrupt, was it done from a local build?
Flags: needinfo?(matt.woodrow)
Comment 19•7 years ago
|
||
No, it was downloaded from here: https://archive.mozilla.org/pub/firefox/candidates/54.0b2-candidates/build1/linux-x86_64/en-US/
Comment 20•7 years ago
|
||
I was also able to reproduce this yesterday in two out of three attempts that I made (on Ubuntu 16.04 64-bit, using a ~2012 4-core dell), with the STR from comment 7, using Nightly with a fresh profile. Unfortunately my crash reports don't have a useful backtrace, for some reason (even though they're from Nightly): bp-eb5ea673-2fa9-4d65-842e-3941d0170425 bp-cc84676d-3856-499a-abbd-9df8a0170425 I tried to reproduce in a debug build (in an attempt to get a useful backtrace) but I couldn't get that to crash. Not sure if that's due to a race condition / opt-vs-debug config difference, or what.
You need to log in
before you can comment on or make changes to this bug.
Description
•