Closed Bug 1381450 Opened 7 years ago Closed 7 years ago

Stylo: Crash when URL get opened from an external application in [ @mozalloc_abort | abort | geckoservo::glue::traverse_subtree]

Categories

(Core :: CSS Parsing and Computation, defect)

56 Branch
Unspecified
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox-esr52 --- unaffected
firefox54 --- unaffected
firefox55 --- unaffected
firefox56 ? fixed

People

(Reporter: whimboo, Assigned: hiro)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

[Tracking Requested - why for this release]: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0 ID:20170714100307 CSet: 67cd1ee26f2661fa5efe3d952485ab3c89af4271 The crash happened already a couple of times in the previous days by simply clicking a link to a Github issue in Thunderbird. In this case it was for https://github.com/mozilla/geckodriver/issues/659#issuecomment-314012348 Report: bp-ebc7a760-b9df-4464-b68e-a94cf0170717. Process Type content (web) MOZ_CRASH Reason MOZ_CRASH() Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x0 Here the first 20 frames of the crashing thread: 0 libmozglue.dylib mozalloc_abort(char const*) memory/mozalloc/mozalloc_abort.cpp:33 1 libmozglue.dylib abort memory/mozalloc/mozalloc_abort.cpp:80 2 XUL std::panicking::rust_panic libpanic_abort/lib.rs:61 3 XUL std::panicking::rust_panic_with_hook libstd/panicking.rs:565 4 XUL std::panicking::begin_panic<collections::string::String> libstd/panicking.rs:511 5 XUL std::panicking::begin_panic_fmt libstd/panicking.rs:495 6 XUL core::panicking::panic_fmt libstd/panicking.rs:471 7 XUL core::panicking::panic libcore/panicking.rs:49 8 XUL geckoservo::glue::traverse_subtree libcore/macros.rs:21 9 XUL geckoservo::glue::Servo_TraverseSubtree servo/ports/geckolib/glue.rs:289 10 XUL <name omitted> layout/style/ServoStyleSet.cpp:386 11 XUL nsCSSFrameConstructor::GetAnonymousContent(nsIContent*, nsIFrame*, nsTArray<nsIAnonymousContentCreator::ContentInfo>&) layout/base/nsCSSFrameConstructor.cpp:4376 12 XUL nsCSSFrameConstructor::ProcessChildren(nsFrameConstructorState&, nsIContent*, nsStyleContext*, nsContainerFrame*, bool, nsFrameItems&, bool, PendingBinding*, nsIFrame*) layout/base/nsCSSFrameConstructor.cpp:11210 13 XUL nsCSSFrameConstructor::ConstructFrameFromItemInternal(nsCSSFrameConstructor::FrameConstructionItem&, nsFrameConstructorState&, nsContainerFrame*, nsFrameItems&) layout/base/nsCSSFrameConstructor.cpp:4165 14 XUL nsCSSFrameConstructor::ConstructFramesFromItem(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList::Iterator&, nsContainerFrame*, nsFrameItems&) layout/base/nsCSSFrameConstructor.cpp:6355 15 XUL nsCSSFrameConstructor::ConstructInline(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItem&, nsContainerFrame*, nsStyleDisplay const*, nsFrameItems&) layout/base/nsCSSFrameConstructor.cpp:10988 16 XUL nsCSSFrameConstructor::ConstructFrameFromItemInternal(nsCSSFrameConstructor::FrameConstructionItem&, nsFrameConstructorState&, nsContainerFrame*, nsFrameItems&) layout/base/nsCSSFrameConstructor.cpp:3983 17 XUL nsCSSFrameConstructor::ConstructFramesFromItem(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList::Iterator&, nsContainerFrame*, nsFrameItems&) layout/base/nsCSSFrameConstructor.cpp:6355 18 XUL nsCSSFrameConstructor::ConstructInline(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItem&, nsContainerFrame*, nsStyleDisplay const*, nsFrameItems&) layout/base/nsCSSFrameConstructor.cpp:10988 19 XUL nsCSSFrameConstructor::ConstructFrameFromItemInternal(nsCSSFrameConstructor::FrameConstructionItem&, nsFrameConstructorState&, nsContainerFrame*, nsFrameItems&) layout/base/nsCSSFrameConstructor.cpp:3983 20 XUL nsCSSFrameConstructor::ConstructFramesFromItem(nsFrameConstructorState&, nsCSSFrameConstructor::FrameConstructionItemList::Iterator&, nsContainerFrame*, nsFrameItems&) layout/base/nsCSSFrameConstructor.cpp:6355
I think this is also related to bug 1371450. The stack has PresShell::HandleEvent. The reason why I think this is not related to bug 1378064 is that this crash has not happened since 20170715 nightly.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Oh, I indeed missed to update my Nightly yesterday morning. Sorry for that extra noise.
Assignee: nobody → hikezoe
Target Milestone: --- → mozilla56
You need to log in before you can comment on or make changes to this bug.