Closed Bug 1340117 Opened 3 years ago Closed 3 years ago

Firefox crash when editing openstreetmap


(Core :: Graphics: Layers, defect, critical)

54 Branch
Not set



Tracking Status
firefox51 --- unaffected
firefox52 --- unaffected
firefox-esr52 --- unaffected
firefox53 --- unaffected
firefox54 + fixed


(Reporter: sydney.gems, Assigned: mattwoodrow)



(Keywords: crash, regression)

Crash Data


(2 files)

Attached file report
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
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
No crash reports in about:crashes?
Severity: normal → critical
Keywords: crash
Crash Signature: [@ mozilla::ipc::FatalError | | 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)?
No, it seems to work fine.
Could you try to narrow down a regression range with the tool mozregression.
See for details.

Run the command "mozregression --good=51" then copy here the final pushlog from repo mozilla-inbound.
Flags: needinfo?(sydney.gems)
Crash Signature: [@ mozilla::ipc::FatalError | | mozilla::layers::PLayerTransactionParent::Read ] → [@ mozilla::ipc::FatalError | | mozilla::layers::PLayerTransactionParent::Read ] [@ mozilla::ipc::FatalError | | mozilla::layers::PLayerTransactionParent::Read]
Ever confirmed: true
Do I need to create an account on OSM to enter into edit mode?
I'm able to re-create similar crash-stacks on linux on current nightly using 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'

Andrew, can you run mozregression to narrow down a regression range in FF53 or 54?
Flags: needinfo?(bugmail)
Crash Signature: [@ mozilla::ipc::FatalError | | mozilla::layers::PLayerTransactionParent::Read ] [@ mozilla::ipc::FatalError | | mozilla::layers::PLayerTransactionParent::Read] → [@ mozilla::ipc::FatalError | | mozilla::layers::PLayerTransactionParent::Read ] [@ mozilla::ipc::FatalError | | mozilla::layers::PLayerTransactionParent::Read] [@ mozilla::ipc::FatalError | | moz…
See Also: → 1340962
Blocks: 1325227
Flags: needinfo?(sydney.gems)
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(bugmail)
Tracking 54+ for this crash regression.
See Also: → 1341807
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.)
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+
Pushed by
Batch ReadLock intializer into a separate IDPL message to avoid hitting the file descriptor limit. r=dvander
Duplicate of this bug: 1341807
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
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:

What do you think about this, Matt?
Flags: needinfo?(matt.woodrow)
Unfortunately that crash report appears to be corrupt, was it done from a local build?
Flags: needinfo?(matt.woodrow)
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):

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.