Closed Bug 1793406 Opened 2 years ago Closed 2 years ago

Crash in [@ RtlEnterCriticalSection | mozilla::RecursiveMutex::LockInternal]

Categories

(Core :: Panning and Zooming, defect)

Unspecified
All
defect

Tracking

()

RESOLVED FIXED
107 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox105 --- unaffected
firefox106 --- unaffected
firefox107 --- fixed

People

(Reporter: gsvelto, Assigned: dlrobertson)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

Crash report: https://crash-stats.mozilla.org/report/index/4862b6e9-3dd0-4197-8100-698a50220930

Reason: EXCEPTION_ACCESS_VIOLATION_WRITE

Top 10 frames of crashing thread:

0 ntdll.dll RtlEnterCriticalSection 
1 xul.dll mozilla::RecursiveMutex::LockInternal xpcom/threads/RecursiveMutex.cpp:69
1 xul.dll mozilla::RecursiveMutex::Lock xpcom/threads/RecursiveMutex.h:30
1 xul.dll mozilla::RecursiveMutexAutoLock::RecursiveMutexAutoLock xpcom/threads/RecursiveMutex.h:79
1 xul.dll mozilla::layers::AsyncPanZoomController::IsRootContent const gfx/layers/apz/src/AsyncPanZoomController.h:1572
1 xul.dll mozilla::layers::WRHitTester::GetAPZCAtPoint gfx/layers/apz/src/WRHitTester.cpp:230
2 xul.dll mozilla::layers::APZCTreeManager::GetTargetAPZC gfx/layers/apz/src/APZCTreeManager.cpp:2824
2 xul.dll mozilla::layers::APZCTreeManager::ReceiveInputEvent gfx/layers/apz/src/APZCTreeManager.cpp:1448
3 xul.dll mozilla::layers::APZInputBridgeParent::RecvReceiveMouseInputEvent gfx/layers/ipc/APZInputBridgeParent.cpp:75
4 xul.dll mozilla::layers::PAPZInputBridgeParent::OnMessageReceived ipc/ipdl/PAPZInputBridgeParent.cpp:299

It seems like we're trying to grab a lock that is NULL.

I think this is a regression from bug 1778120. It's unclear to me at the moment why we'd have a lock that is null there.

It's probably the APZC itself that's null. It shouldn't be, but this block suggests it sometimes is for a reason we don't understand, and here we are defensive and null-check it, so we should probably null-check it for the IsRootContent() call as well.

(In reply to Botond Ballo [:botond] from comment #2)

It's probably the APZC itself that's null. It shouldn't be, but this block suggests it sometimes is for a reason we don't understand, and here we are defensive and null-check it, so we should probably null-check it for the IsRootContent() call as well.

Makes sense. I thought the MOZ_ASSERT would be run in Nightly. Is that not the case?

Regressed by: 1778120

Set release status flags based on info from the regressing bug 1778120

If no target APZC was found, there is no need to check the fixed position side
bits of the hit.

Assignee: nobody → drobertson
Status: NEW → ASSIGNED
Attachment #9297628 - Attachment description: Bug 1793406 - Do not check hit side bits if no target APZC was found. r=botond → Bug 1793406 - Guard against a null pointer deref if no APZC was found. r=botond
Pushed by drobertson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cf96a8764a2a
Guard against a null pointer deref if no APZC was found. r=botond
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 107 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: