1707518 - Crash in [@ mozilla::dom::BrowsingContext::PreOrderWalkVoid]

Status: RESOLVED INCOMPLETE

(Core :: DOM: Navigation, defect, P2)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Signature changed in the 89 development cycle due to bug 1572084 from [@ mozilla::dom::BrowsingContext::PreOrderWalk] (5 crashes from 5 installations) to [@ mozilla::dom::BrowsingContext::PreOrderWalkVoid] (4 crashes from 4 installations)

Crash report: https://crash-stats.mozilla.org/report/index/9d9e3560-0e1c-4f31-8a3a-e4eee0210425

Reason: EXC_BAD_ACCESS / EXC_I386_GPFLT

Top 6 frames of crashing thread:

0 XUL mozilla::dom::BrowsingContext::PreOrderWalkVoid docshell/base/BrowsingContext.cpp:1007
1 XUL XPCRootSetElem::RemoveFromRootSet js/xpconnect/src/XPCJSRuntime.cpp:3122
2 XUL nsXPCWrappedJS::Release js/xpconnect/src/XPCWrappedJS.cpp:280
3 XUL nsSHistory::PurgeHistory docshell/shistory/nsSHistory.cpp:1051
4 XUL NS_InvokeByIndex 
5 XUL XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1142

Comment 1

[Andrew McCreight [:mccr8]]

This stack doesn't make much sense. The crash in comment 0 is a null-deref crash. nsSHistory::PurgeHistory calls PreOrder walk, but I don't understand why the two frames related to XPCWJS are in the stack. I don't see any reason that XPCWJS::Release would be called there. Maybe the stack walker is getting confused by some lambda goo.

Comment 2

[Chris Peterson [:cpeterson]]

Assigning to Peter because he is going to look at possibly-duplicate bug 1707578.

Comment 3

[Gabriele Svelto [:gsvelto] (PTO)]

I found what looks like another instance of this crash. Some of the crashes under this new signature and the old ones too appear to be UAFs, but most do not.

Comment 4

[Andrew McCreight [:mccr8]]

This is still happening very rarely on ESR102 but not on other supported branches.