I have a patch for bug 1392235, but trying to load the website that triggers that bug now hits a completely unrelated EXC_BAD_ACCESS stylo crash at: core::slice::ptrdistance<style::properties::longhands::transform::computed_value::ComputedOperation> core::slice::{{impl}}::size_hint<style::properties::longhands::transform::computed_value::ComputedOperation> core::iter::traits::ExactSizeIterator::len<core::slice::Iter<style::properties::longhands::transform::computed_value::ComputedOperation>> core::iter::{{impl}}::new<core::slice::Iter<style::properties::longhands::transform::computed_value::ComputedOperation>,core::slice::Iter<style::properties::longhands::transform::computed_value::ComputedOperation>> core::iter::iterator::Iterator::zip<core::slice::Iter<style::properties::longhands::transform::computed_value::ComputedOperation>,&[style::properties::longhands::transform::computed_value::ComputedOperation]> style::properties::animated_properties::{{impl}}::animate style::properties::animated_properties::{{impl}}::animate geckoservo::glue::Servo_AnimationCompose mozilla::dom::KeyframeEffectReadOnly::ComposeStyleRule(RawServoAnimationValueMap&, mozilla::AnimationProperty const&, mozilla::AnimationPropertySegment const&, mozilla::ComputedTiming const&) The test site was set up by swav (CC'ed) and requires a username or password which either swav or I can can make available to anyone that wants to debug this. Note that debugging this will require the fix for bug 1392235.

I'm still trying to get the credentials needed to reproduce this, but looking at the stack in comment 0, it looks like we're here somewhere: http://searchfox.org/mozilla-central/rev/67f38de2443e6b613d874fcf4d2cd1f2fc3d5e97/servo/components/style/properties/helpers/animated_properties.mako.rs#2253

That said, it might well be the call site to blame. jwatt, ping on the credentials for the site to repro this?

(In reply to Brian Birtles (:birtles, away until 19 Sep) from comment #1) > I'm still trying to get the credentials needed to reproduce this, but > looking at the stack in comment 0, it looks like we're here somewhere: I am quite in disbelief that the issue could be coming from Rust's libstd's zip iterator indeed. The issue is probably in the caller.

Though, was the bug ever reproduced on a debug build? I wonder if some assertions either in Gecko or Stylo would fail, maybe the current code for transform lists breaks some unspoken invariant about the representation of transform lists or something like that.

(In reply to Brian Birtles (:birtles, away until 19 Sep) from comment #2) > That said, it might well be the call site to blame. jwatt, ping on the > credentials for the site to repro this? Sent.

Can you repro with STYLO_THREADS=1? If not, I'm moderately sure this is a stack overflow that should be already fixed.

Also, can you repro in a revision after [1], where we bumped the stack size? [1] https://hg.mozilla.org/integration/autoland/rev/95543c372e9f9def5a42d71d4d5356917a031a89

(If this turns out to be unrelated to the stack stuff, we should re-bump the priority).

I can't reproduce the crash on the revision, bf29e38baf5d, which is a prior commit of the revision in comment 7. I did apply the jwatt's patch <https://hg.mozilla.org/integration/mozilla-inbound/rev/f574c304f748> . Note that I tested on Linux with debug build. I can't reproduce the crash on today's m-c (ea7b55d65d76) with the patch either. But I got another assertion when I clicked somewhere on the site with the today's m-c build. The assertion is 'Assertion failure: mCoalescedInputEvent->buttons == aEvent.buttons, at /home/ikezoe/stylo/dom/ipc/CoalescedMouseData.cpp:33', so I think it's not related to stylo. [1] https://hg.mozilla.org/integration/autoland/rev/bf29e38baf5d25933128d6e564ae732a422a2837

:jwatt, can you still reproduce the crash on m-c? If so, is there any STR to reproduce the crash reliably?

Optimistically resolving as a dupe of bug 1395708, please re-open if you still see it.