Open Bug 1528554 Opened 2 years ago Updated 2 years ago

Crash in [@ mozilla::InternalFormEvent::~InternalFormEvent]

Categories

(Core :: DOM: Animation, defect, P3)

66 Branch
Unspecified
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: beldirai, Unassigned)

Details

(Keywords: regression)

Crash Data

Note: I am very bad at filing bugs, so I apologize if I got something wrong.

This bug is for crash report bp-cd38f6ac-13d9-4cf3-ab51-359ab0190215.

Top 10 frames of crashing thread:

0 xul.dll void mozilla::InternalFormEvent::~InternalFormEvent widget/BasicEvents.h:498
1 xul.dll void mozilla::dom::AnimationEvent::~AnimationEvent dom/events/AnimationEvent.h:40
2 xul.dll SnowWhiteKiller::~SnowWhiteKiller xpcom/base/nsCycleCollector.cpp:2416
3 xul.dll nsCycleCollector::Collect xpcom/base/nsCycleCollector.cpp:3407
4 xul.dll nsCycleCollector_collectSlice xpcom/base/nsCycleCollector.cpp:3955
5 xul.dll static void nsJSContext::RunCycleCollectorSlice dom/base/nsJSEnvironment.cpp:1471
6 xul.dll static bool CCRunnerFired dom/base/nsJSEnvironment.cpp:1853
7 xul.dll std::_Func_impl_no_alloc<bool  
8 xul.dll mozilla::IdleTaskRunner::Run xpcom/threads/IdleTaskRunner.cpp:58
9 xul.dll static void mozilla::TimedOut xpcom/threads/IdleTaskRunner.cpp:78

I apologize if this bug report seems incompetent. I'm an end-user so I don't quite understand how coding works, or where to look for additional information.

If there is any need for any additional reports (like about:memory or about:support), I'll be happy to help. Any tips on where to look for stuff would also be great - I'll try to dig deeper if needed.

Can you please provide steps to reproduce this crash or the details how this crash happened, so that I could try to reproduce this issue?

About: support and about:memory info would be appreciated too. Thanks!

Flags: needinfo?(beldirai)

I think most of the crashes I get actually occur from hanging - I tend to keep the browser on for several hours (sometimes days), and after a while every website will start to hang. No matter if it's Google's search engine, Wikipedia or Youtube, the website hangs after around 6-7 hours and website links from Google won't even load anymore (they just get stuck in a loop of loading).

Around the time of this crash, I think I was actually reading my Hotmail/Outlook emails. The browser froze (into the gray "Not responding" stage) and then crashed.

Flags: needinfo?(beldirai)

Oh yes, here's the about:support and about:memory files.

https://textuploader.com/15922 - support. I had to do an unedited version since the "clean" version was only in Finnish.
https://ufile.io/chrbm - memory. Hope that helps!

It looks like the crash is happening inside a browser process so moving to Core::DOM.

Also, for future reference you can attach files to the bug so you don't have to use an external uploading site.

Component: Untriaged → DOM
Product: Firefox → Core

The crash started showing up on Desktop in 65.
Could bug 1397297 be related?

Flags: needinfo?(bugs)
Keywords: regression

Maybe, though that landed to FF63.
But this looks more like just crashing in somewhat random place when cycle collector is releasing something already deleted.
Looking some more tomorrow.

(And I'm happy read anything in Finnish ;) )

I wonder if we did some changes to AnimationEvent firing, since many of the stack traces have that.
(InternalFormEvent is bogus)

Flags: needinfo?(bugs)
Flags: needinfo?(bugs)
Component: DOM → DOM: Core & HTML
Priority: -- → P3

I had a dig around animation changes in 65 but didn't find anything suspicious.

Bug 1488122 is about the most significant change I can see there but nothing about it seems suspicious. It could cause extra restyles in some cases (but only when there is an implicit from/to keyframe--all other cases are not enabled on release builds) which could cause some elements to live for an extra frame but the crash here seems more likely to occur if something was released earlier, not later.

As for the AnimationEvent class itself, it doesn't add anything interesting to WidgetEvent and hasn't been touched for quite a while. Perhaps more importantly, as far as I can tell we haven't changed anything related to its dispatching in that time frame either.

(For my own notes, the stack in comment 0 suggests the AnimationEvent dtor is calling the InternalFormEvent dtor but if you following the source link it appears it is actually the WidgetEvent dtor that is called.)

Looking at the other crashes for ~AnimationEvent over the last 9 months or so it seems they're all on Windows:

https://crash-stats.mozilla.com/signature/?signature=mozilla%3A%3Adom%3A%3AAnimationEvent%3A%3A~AnimationEvent&date=%3E%3D2018-07-01T13%3A33%3A00.000Z&date=%3C2019-05-17T13%3A33%3A00.000Z#aggregations

There doesn't appear to be any change in their volume over time (unlike crashes with the ~InternalFormEvent signature) or by release. In the ~InternalFormEvent signature is just a variant on ~AnimationEvent, then 65 might not be the right time frame to consider.

Flags: needinfo?(bbirtles)
You need to log in before you can comment on or make changes to this bug.