It looks like the only remaining attached signature with crashes [@ RtlAcquireSRWLockExclusive | mozilla::OffTheBooksMutex::Lock | mozilla::detail::BaseAutoLock<T>::BaseAutoLock ] is now not as tied to Qihoo, so the title has become potentially misleading? Regarding the bug itself, I wonder if we are just seeing here the consequence of a variety of heap buffer overflows, and locks are just the kind of objects that are used so often that it makes it very likely to crash very soon after corruption compared to other objects?
Bug 1706031 Comment 17 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
It looks like the only remaining attached signature with crashes [@ RtlAcquireSRWLockExclusive | mozilla::OffTheBooksMutex::Lock | mozilla::detail::BaseAutoLock<T>::BaseAutoLock ] is now not as tied to Qihoo, so the title has become potentially misleading? Regarding the bug itself, I wonder if we are just seeing here the consequence of a variety of heap buffer overflows, and locks are just the kind of objects that are used so often that it makes it very likely to crash very soon after being corrupted compared to other objects?
It looks like the only remaining attached signature with crashes [@ RtlAcquireSRWLockExclusive | mozilla::OffTheBooksMutex::Lock | mozilla::detail::BaseAutoLock<T>::BaseAutoLock ] is now not as tied to Qihoo, so the title has become potentially misleading? Regarding that specific signature, I wonder if we are just seeing here the consequence of a variety of heap buffer overflows, and locks are just the kind of objects that are used so often that it makes it very likely to crash very soon after being corrupted compared to other objects?
It looks like the only remaining attached signature with crashes [@ RtlAcquireSRWLockExclusive | mozilla::OffTheBooksMutex::Lock | mozilla::detail::BaseAutoLock<T>::BaseAutoLock ] is now not as tied to Qihoo, so the title has become potentially misleading? Regarding that specific signature, I wonder if we are just seeing here the consequence of a variety of heap buffer overflows, and locks are just the kind of objects that are used so often that it makes it very likely to crash very soon after being corrupted compared to other objects? See for example [this crash report](https://crash-stats.mozilla.org/report/index/107be29f-56bf-425f-8a12-3c6580230212#tab-details) where the pointer to the lock object is stored in a static variable.