Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
REGRESSION(255600@main): [ iOS ] ASSERTION FAILED: threadLikeAssertio…
…n.isCurrent() hit by TestWebKitAPI.WebKit.RequestRectForFoundTextRange every time https://bugs.webkit.org/show_bug.cgi?id=246656 rdar://101266728 Reviewed by Darin Adler. The deleted value of a `WebFoundTextRange` is currently constructed using copy assignment. This is incorrect as the deleted value is intended to be written into an uninitialized storage buffer. The use of copy assignment results in the destruction of an uninitialized StringImpl, followed by an OOB write in `StringImpl::deref()`. Note that 255600@main is not the root cause of the issue. However, after 255600@main, the OOB write results in the address of the `completionHandler` passed into `WebFoundTextRangeController::requestRectForFoundTextRange` being modified. Consequently, `completionHandler.m_callThread.m_uid` is set to a garbage value, and the assertion is hit as there is now a mismatch between the calling thread and stored initialization thread. To fix, use operator new to construct the deleted value. Additionally, use `HashTableDeletedValue` when contructed the deleted AtomString for correctness. * Source/WebKit/Shared/WebFoundTextRange.cpp: (WebKit::WebFoundTextRange::operator== const): (WebKit::WebFoundTextRange::decode): * Source/WebKit/Shared/WebFoundTextRange.h: (WTF::HashTraits<WebKit::WebFoundTextRange>::emptyValue): (WTF::HashTraits<WebKit::WebFoundTextRange>::constructDeletedValue): (WTF::HashTraits<WebKit::WebFoundTextRange>::isDeletedValue): (WTF::HashTraits<WebKit::WebFoundTextRange>::deletedValue): Deleted. Canonical link: https://commits.webkit.org/255832@main
- Loading branch information
After you landed this, I realized that we don’t ever decode hash table deleted values when decoding an atom string, so this check is unnecessary dead code.