Open Bug 1394516 Opened 3 years ago Updated 3 years ago

crash in [@ nsRange::UnregisterCommonAncestor]

Categories

(Core :: DOM: Selection, defect, P4)

defect

Tracking

()

Tracking Status
firefox57 --- affected

People

(Reporter: tsmith, Unassigned)

Details

(Keywords: crash, csectype-nullptr)

Attachments

(1 file)

Attached file asan_log.txt
This bug was found by a long running fuzz job. No test cases are available. If this log is not useful please close the bug.

Found using m-c:
BuildID=20170714164113
SourceStamp=2908b6171cb8df85fc1f0985e2bf94ce3b04a522
Catalin has been looking at the nsRange a bunch recently so he may have thoughts. If not him, maybe Mats can take a quick look.

Either/both of you: please feel free to close this if nothing jumps out.
Flags: needinfo?(mats)
Flags: needinfo?(catalin.badea392)
Priority: -- → P3
We could null check the result of aNode->GetExistingCommonAncestorRanges() at http://searchfox.org/mozilla-central/source/dom/base/nsRange.cpp#428 which is what's probably causing the crash.
Flags: needinfo?(catalin.badea392)
Fwiw, the hashtable has since been replaced by nsRange inheriting LinkedListElement.
This crash still occurs in the wild, but in extremely low volume.
E.g. in 61.0b7: bp-922e488e-dba5-4424-874b-7ef530180522
It seems the valid reports are null-pointer crashes.

I guess we could upgrade the assertions in UnregisterCommonAncestor
to MOZ_DIAGNOSTIC_ASSERTs to make it more likely to catch.
I think it's low priority though...
Component: DOM → Selection
Flags: needinfo?(mats)
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.