1972341 - Crash in [@ mozilla::dom::Event::GetTarget] on family 6 model 183 stepping 1

Status: NEW

(Core :: DOM: Events, defect)

Description

[Markus Stange [:mstange]]

Couldn't see an existing bug about this crash, and it seems like a really frequent crash, #10 on https://crash-stats.mozilla.org/topcrashers/?product=Firefox&version=139.0.4

Crash report: https://crash-stats.mozilla.org/report/index/3cfcef58-d807-4950-bc46-efc1b0250616

Reason:

EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames:

0  xul.dll  mozilla::dom::Event::GetTarget() const  dom/events/Event.cpp:279
0  xul.dll  mozilla::dom::Event_Binding::get_target(JSContext*, JS::Handle<JSObject*>, vo...  dom/bindings/EventBinding.cpp:262
1  ?  @0x0000033c865c2b5f
2  xul.dll  <unknown in xul.pdb>
3  xul.dll  js::AutoCheckRecursionLimit::checkLimitImpl(unsigned long long, void*) const  js/public/friend/StackLimits.h:198
3  xul.dll  js::AutoCheckRecursionLimit::checkWithStackPointerDontReport(JSContext*, void...  js/public/friend/StackLimits.h:267
3  xul.dll  js::AutoCheckRecursionLimit::checkDontReport(JSContext*) const  js/public/friend/StackLimits.h:251
3  xul.dll  js::AutoCheckRecursionLimit::check(JSContext*) const  js/public/friend/StackLimits.h:233
3  xul.dll  CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::...  js/src/vm/Interpreter.cpp:478
3  xul.dll  js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstru...  js/src/vm/Interpreter.cpp:590

Comment 1

[Markus Stange [:mstange]]

[Tracking Requested - why for this release]: Appears to be a regression in 139.

Judging by the Nightly graph, caused by something that landed in late April / early May.

Comment 2

[Andrew McCreight [:mccr8]]

These look like null deref crashes. What is the reason you marked this as a security bug?

Comment 3

[Andrew McCreight [:mccr8]]

Olli, any guesses here? Maybe the event is unlinked? I don't see a ton of information in the stack unfortunately.

Comment 4

[Markus Stange [:mstange]]

(In reply to Andrew McCreight [:mccr8] from comment #2)

These look like null deref crashes. What is the reason you marked this as a security bug?

I was extra cautious because I wasn't sure and wasn't fully awake yet. Can you make the bug non-security-sensitive?

Comment 5

[Markus Stange [:mstange]]

Here's a pushlog for changes between Nightly builds 20250428211601 and 20250502094430: https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=ba56f7ee55792aaf974891449b64ace32bc9e1b8&tochange=5b5bd7e730096ef3867efe107dc97fb4a38a489a

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

AutoCheckRecursionLimit on the stack seems valid, but higher up, not so sure.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox140 (beta) and tracked for firefox141 (nightly). We have limited time to fix this, the soft freeze is in 2 days. However, the bug still isn't assigned.

:hsinyi, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 8

[Andrew McCreight [:mccr8]]

The stacks don't really make any sense here. As is, I'm not sure this bug is actionable.

Comment 9

[Markus Stange [:mstange]]

How can we make it actionable? Based on the graph it looks very real.
75.3% parent process
24.7% content process

Maybe someone can load the minidump into visual studio and check if the stack makes more sense there?

Comment 10

[Andrew McCreight [:mccr8]]

Looking at the correlations tab for crashes with this signature I see this:

(96.84% in signature vs 07.23% overall) CPU Info = family 6 model 183 stepping 1

So I think this is a CPU bug (this is the exact CPU as in bug 1876939).

Comment 11

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: I think the tracking should be dropped for this bug. I don't think we should track a CPU bug. The crash volume isn't too high.