Closed Bug 1479681 Opened 7 years ago Closed 7 years ago

Hang in LonghandId::to_physical (Servo_ResolveLogicalProperty) on TweetDeck

Categories

(Core :: CSS Parsing and Computation, defect)

Unspecified
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- unaffected
firefox62 --- unaffected
firefox63 + fixed

People

(Reporter: pascalc, Assigned: emilio)

References

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is report bp-673a4c10-9a0e-4aed-9feb-5aa5e0180731. ============================================================= Top 10 frames of crashing thread: 0 libxul.so style::properties::LonghandId::to_physical::he10d2a91754ae90b 1 libxul.so Servo_ResolveLogicalProperty servo/ports/geckolib/glue.rs:925 2 libxul.so nsTransitionManager::UpdateTransitions [clone .cold.98] 3 libxul.so Gecko_UpdateAnimations 4 libxul.so core::ptr::drop_in_place servo/components/style/gecko/wrapper.rs:1513 5 libxul.so geckoservo::glue::traverse_subtree servo/components/style/driver.rs:182 6 libxul.so Servo_TraverseSubtree servo/ports/geckolib/glue.rs:351 7 libxul.so mozilla::ServoStyleSet::StyleDocument 8 libxul.so mozilla::RestyleManager::DoProcessPendingRestyles 9 libxul.so mozilla::PresShell::DoFlushPendingNotifications =============================================================
This is 100% reproducible in a fresh profile when logging in Tweetdeck
Summary: Crash in IPCError-browser | ShutDownKill → Crash in LonghandId::to_physical (Servo_ResolveLogicalProperty) on TweetDesk
happening on a highly visible site and reproducible, tracking for 63
No crash happens on local build rev: a37ba2f75a3521e5b587ae340ef345f167abae39, hopefully it got fixed?
(In reply to Hiroyuki Ikezoe (:hiro) (PTO on Aug 20) from comment #5) > No crash happens on local build rev: > a37ba2f75a3521e5b587ae340ef345f167abae39, hopefully it got fixed? This one is a local revision. The correct one is fe2acb8f775a787b9027a5b46b59eeb1f73f5c63.
Oops. I hadn't login there. Sorry for confusing.
Emilio?
Blocks: 1478990
Flags: needinfo?(emilio)
Yup yup, looking. Thanks!
Assignee: nobody → emilio
Flags: needinfo?(emilio)
Summary: Crash in LonghandId::to_physical (Servo_ResolveLogicalProperty) on TweetDesk → Crash in LonghandId::to_physical (Servo_ResolveLogicalProperty) on TweetDeck
Summary: Crash in LonghandId::to_physical (Servo_ResolveLogicalProperty) on TweetDeck → Hang in LonghandId::to_physical (Servo_ResolveLogicalProperty) on TweetDeck
The loop was mutating the nsCSSPropertyID used to guard the exit, which is obviously wrong. This branch is pretty rarely taken, since people don't usually specify `all` as a transition property other than the first, for which case we take the fast path with `checProperties = false`. Our test-suite failed to catch this. Added a crashtest that hangs without this patch. The reason bug 1478990 regressed this is because it changed the order of nsCSSPropertyID so that `p` actually went backwards causing the infinite loop, but the bug was introduced (by me, whoops) in bug 1309752.
Comment on attachment 8996247 [details] Bug 1479681: Fix the loop in nsTransitionManager dealing with stopping `all` transitions. r=hiro Hiroyuki Ikezoe (:hiro) (PTO on Aug 20) has approved the revision. https://phabricator.services.mozilla.com/D2552
Attachment #8996247 - Flags: review+
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/mozilla-inbound/rev/78be4bbf4b05 Fix the loop in nsTransitionManager dealing with stopping `all` transitions. r=hiro
Pushed by shindli@mozilla.com: https://hg.mozilla.org/mozilla-central/rev/0d72c7996d60 Fix the loop in nsTransitionManager dealing with stopping `all` transitions. r=hiro a=aryx
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: