This is still quite high volume in 115.0.2. User comments still talk about deleting history. (In reply to Emilio Cobos Álvarez (:emilio) from comment #1) > Ok, this one I can't explain unless there's already a freed or corrupt pointer in `nsTreeBodyFrame::mView`? The crash address is also not poison, so that's weird... (In reply to Daniel Holbert [:dholbert] (away until Jul 24, for PTO & CSSWG meeting) from comment #14) > The crash seems to reliably be on `0x7ffffffff0de7fff`, too, which is kinda odd. This would be because we call `nsTreeBodyFrame::GetSelection` on an `nsTreeBodyFrame` for which `mView.mRawPtr` points to an `nsView` which already went through `nsView::Destroy`. [When we destroy an `nsView`](https://searchfox.org/mozilla-central/source/view/nsView.cpp#168-172), we do `mozWritePoison(this, sizeof(*this));`. This will overwrite the layout of the object with ` gMozillaPoisonValue`, which is `0x7ffffffff0de7fff` in x64 (even though it is not hardcoded in the code base, that is the value it takes). Then, we will crash if we try to access a field from that object (here, when we access the vtable). These crashes indicate use-after-poison, with our own custom poisoning as defined in `mfbt/Poison.h`.
Bug 1809492 Comment 21 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This is still quite high volume in 115.0.2. User comments still talk about deleting history. (In reply to Emilio Cobos Álvarez (:emilio) from comment #1) > Ok, this one I can't explain unless there's already a freed or corrupt pointer in `nsTreeBodyFrame::mView`? The crash address is also not poison, so that's weird... (In reply to Daniel Holbert [:dholbert] (away until Jul 24, for PTO & CSSWG meeting) from comment #14) > The crash seems to reliably be on `0x7ffffffff0de7fff`, too, which is kinda odd. This would be because we call `nsTreeBodyFrame::GetSelection` on an `nsTreeBodyFrame` for which `mView.mRawPtr` points to an `nsView` which has already been freed. When we [free the object](https://searchfox.org/mozilla-central/source/memory/build/mozjemalloc.cpp#3767), we will overwrite the layout of the object with ` gMozillaPoisonValue`, which is `0x7ffffffff0de7fff` in x64 (even though it is not hardcoded in the code base, that is the value it takes). Then, we will crash if we try to access a field from that object (here, when we access the vtable). These crashes indicate use-after-poison, with our own custom poisoning as defined in `mfbt/Poison.h`.
This is still quite high volume in 115.0.2. User comments still talk about deleting history. (In reply to Emilio Cobos Álvarez (:emilio) from comment #1) > Ok, this one I can't explain unless there's already a freed or corrupt pointer in `nsTreeBodyFrame::mView`? The crash address is also not poison, so that's weird... (In reply to Daniel Holbert [:dholbert] (away until Jul 24, for PTO & CSSWG meeting) from comment #14) > The crash seems to reliably be on `0x7ffffffff0de7fff`, too, which is kinda odd. This would be because we call `nsTreeBodyFrame::GetSelection` on an `nsTreeBodyFrame` for which `mView.mRawPtr` points to an `nsView` which has already been freed. When we [free the object](https://searchfox.org/mozilla-central/source/memory/build/mozjemalloc.cpp#3767), we will overwrite the layout of the object with ` gMozillaPoisonValue`, which is `0x7ffffffff0de7fff` in x64 (even though it is not hardcoded in the code base, that is the value it takes). Then, we will crash if we try to access a field from that object (here, when we access the vtable). These crashes indicate use-after-poison, with our own custom poisoning as defined in `mfbt/Poison.h`. Edit: Updated following comment 22. Sorry for the confusion.
This is still quite high volume in 115.0.2. User comments still talk about deleting history. (In reply to Emilio Cobos Álvarez (:emilio) from comment #1) > Ok, this one I can't explain unless there's already a freed or corrupt pointer in `nsTreeBodyFrame::mView`? The crash address is also not poison, so that's weird... (In reply to Daniel Holbert [:dholbert] (away until Jul 24, for PTO & CSSWG meeting) from comment #14) > The crash seems to reliably be on `0x7ffffffff0de7fff`, too, which is kinda odd. This would be because we call `nsTreeBodyFrame::GetSelection` on an `nsTreeBodyFrame` for which `mView.mRawPtr` points to an `nsITreeView` which has already been freed. When we [free the object](https://searchfox.org/mozilla-central/source/memory/build/mozjemalloc.cpp#3767), we will overwrite the layout of the object with ` gMozillaPoisonValue`, which is `0x7ffffffff0de7fff` in x64 (even though it is not hardcoded in the code base, that is the value it takes). Then, we will crash if we try to access a field from that object (here, when we access the vtable). These crashes indicate use-after-poison, with our own custom poisoning as defined in `mfbt/Poison.h`. Edit: Updated following comment 22. Sorry for the confusion.
This is still quite high volume in 115.0.2. User comments still talk about deleting history. (In reply to Emilio Cobos Álvarez (:emilio) from comment #1) > Ok, this one I can't explain unless there's already a freed or corrupt pointer in `nsTreeBodyFrame::mView`? The crash address is also not poison, so that's weird... (In reply to Daniel Holbert [:dholbert] (away until Jul 24, for PTO & CSSWG meeting) from comment #14) > The crash seems to reliably be on `0x7ffffffff0de7fff`, too, which is kinda odd. This would be because we call `nsTreeBodyFrame::GetSelection` on an `nsTreeBodyFrame` for which `mView.mRawPtr` points to an `nsITreeView` which has already been freed. When we [free the object](https://searchfox.org/mozilla-central/source/memory/build/mozjemalloc.cpp#3767), we will overwrite the layout of the object with ` gMozillaPoisonValue`, which is `0x7ffffffff0de7fff` in x64 (even though it is not hardcoded in the code base, that is the value it takes). Then, we will crash if we try to access a field from that object (here, when we access the vtable). These crashes indicate use-after-poison, with our own custom poisoning as defined in `mfbt/Poison.h`. Edit: Updated following comment 22. Sorry for the confusion. Edit 2: Sorry, I think my comment is still wrong. I will do a more accurate update tomorrow.