Another suspicious part in the code is [the `kungfuDeathGrip` in `XULTreeElement::GetTreeBodyFrame()`](https://searchfox.org/mozilla-central/source/dom/xul/XULTreeElement.cpp#84). I suppose that this is present to guarantee that the `XULTreeElement` object lives at least until the end of `XULTreeElement::GetTreeBodyFrame()`, even if the refcount drops to 0 during `doc->FlushPendingNotifications(aFlushType);`. But what about when we come out of `XULTreeElement::GetTreeBodyFrame()`? I wonder if we could be observing the following scenario: - the `XULTreeElement` and its `nsTreeBodyFrame` are both alive and well; - `XULTreeElement::SetFocused()` calls into `XULTreeElement::GetTreeBodyFrame()`; - in `XULTreeElement::GetTreeBodyFrame()`, after `doc->FlushPendingNotifications(aFlushType);`, the refcount for the `XULTreeElement` reaches 1: the `kungfuDeathGrip` saved us from reaching 0; - so far the `XULTreeElement` and its `nsTreeBodyFrame` are still both alive and well; - so we are able to collect a `nsTreeBodyFrame*` (or recycle the cached one), which gets returned as a result; - but as we exit `XULTreeElement::GetTreeBodyFrame()`, the `kungfuDeathGrip` destructor makes the refcount for the `XULTreeElement` fall to 0, so the `XULTreeElement` is freed, along with its `nsTreeBodyFrame` (it it the case that freeing the `XULTreeElement` also frees the `nsTreeBodyFrame`? I'm not sure about that part); - we obtained a pointer to the `nsTreeBodyFrame` as a result of calling `XULTreeElement::GetTreeBodyFrame()`, but this object is now freed and poisoned; - as we try to use the poisoned object, we crash on poison value `0x7ffffffff0de7fff`. Do we perhaps need an extra `kungfuDeathGrip` in the scope of `XULTreeElement::SetFocused()`, or a way to detect that the objects were freed as we exited `XULTreeElement::GetTreeBodyFrame()`?
Bug 1809492 Comment 27 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Another suspicious part in the code is [the `kungfuDeathGrip` in `XULTreeElement::GetTreeBodyFrame()`](https://searchfox.org/mozilla-central/source/dom/xul/XULTreeElement.cpp#84). I suppose that this is present to guarantee that the `XULTreeElement` object lives at least until the end of `XULTreeElement::GetTreeBodyFrame()`, by preventing the refcount from droping to 0 during the `doc->FlushPendingNotifications(aFlushType)` call. But what about when we come out of `XULTreeElement::GetTreeBodyFrame()`? I wonder if we could be observing the following scenario: - the `XULTreeElement` and its `nsTreeBodyFrame` are both alive and well; - `XULTreeElement::SetFocused()` calls into `XULTreeElement::GetTreeBodyFrame()`; - in `XULTreeElement::GetTreeBodyFrame()`, after `doc->FlushPendingNotifications(aFlushType);`, the refcount for the `XULTreeElement` reaches 1: the `kungfuDeathGrip` saved us from reaching 0; - so far the `XULTreeElement` and its `nsTreeBodyFrame` are still both alive and well; - so we are able to collect a `nsTreeBodyFrame*` (or recycle the cached one), which gets returned as a result; - but as we exit `XULTreeElement::GetTreeBodyFrame()`, the `kungfuDeathGrip` destructor makes the refcount for the `XULTreeElement` fall to 0, so the `XULTreeElement` is freed, along with its `nsTreeBodyFrame` (it it the case that freeing the `XULTreeElement` also frees the `nsTreeBodyFrame`? I'm not sure about that part); - we obtained a pointer to the `nsTreeBodyFrame` as a result of calling `XULTreeElement::GetTreeBodyFrame()`, but this object is now freed and poisoned; - as we try to use the poisoned object, we crash on poison value `0x7ffffffff0de7fff`. Do we perhaps need an extra `kungfuDeathGrip` in the scope of `XULTreeElement::SetFocused()`, or a way to detect that the objects were freed as we exited `XULTreeElement::GetTreeBodyFrame()`?
Another suspicious part in the code is [the `kungfuDeathGrip` in `XULTreeElement::GetTreeBodyFrame()`](https://searchfox.org/mozilla-central/source/dom/xul/XULTreeElement.cpp#84). I suppose that this is present to guarantee that the `XULTreeElement` object lives at least until the end of `XULTreeElement::GetTreeBodyFrame()`, by preventing the refcount from droping to 0 during the `doc->FlushPendingNotifications(aFlushType)` call. But what about when we come out of `XULTreeElement::GetTreeBodyFrame()`? I wonder if we could be observing the following scenario: - the `XULTreeElement` and its `nsTreeBodyFrame` are both alive and well; - `XULTreeElement::SetFocused()` calls into `XULTreeElement::GetTreeBodyFrame()`; - in `XULTreeElement::GetTreeBodyFrame()`, after `doc->FlushPendingNotifications(aFlushType);`, the refcount for the `XULTreeElement` reaches 1 as the `kungfuDeathGrip` just saved us from reaching 0; - so far the `XULTreeElement` and its `nsTreeBodyFrame` are still both alive and well; - so we are able to collect a `nsTreeBodyFrame*` (or recycle the cached one), which gets returned as a result; - but as we exit `XULTreeElement::GetTreeBodyFrame()`, the `kungfuDeathGrip` destructor makes the refcount for the `XULTreeElement` fall to 0, so the `XULTreeElement` is freed, along with its `nsTreeBodyFrame` (it it the case that freeing the `XULTreeElement` also frees the `nsTreeBodyFrame`? I'm not sure about that part); - we obtained a pointer to the `nsTreeBodyFrame` as a result of calling `XULTreeElement::GetTreeBodyFrame()`, but this object is now freed and poisoned; - as we try to use the poisoned object, we crash on poison value `0x7ffffffff0de7fff`. Do we perhaps need an extra `kungfuDeathGrip` in the scope of `XULTreeElement::SetFocused()`, or a way to detect that the objects were freed as we exited `XULTreeElement::GetTreeBodyFrame()`?
Another suspicious part in the code is [the `kungfuDeathGrip` in `XULTreeElement::GetTreeBodyFrame()`](https://searchfox.org/mozilla-central/source/dom/xul/XULTreeElement.cpp#84). I suppose that this is present to guarantee that the `XULTreeElement` object lives at least until the end of `XULTreeElement::GetTreeBodyFrame()`, by preventing the refcount from droping to 0 during the `doc->FlushPendingNotifications(aFlushType)` call. But what about when we come out of `XULTreeElement::GetTreeBodyFrame()`? I wonder if we could be observing the following scenario: - the `XULTreeElement` and its `nsTreeBodyFrame` are both alive and well; - `XULTreeElement::SetFocused()` calls into `XULTreeElement::GetTreeBodyFrame()`; - in `XULTreeElement::GetTreeBodyFrame()`, after `doc->FlushPendingNotifications(aFlushType);`, the refcount for the `XULTreeElement` reaches 1 as the `kungfuDeathGrip` just saved us from reaching 0; - so far the `XULTreeElement` and its `nsTreeBodyFrame` are still both alive and well; - so we are able to collect a `nsTreeBodyFrame*` (or recycle the cached one), which we will return as a result; - but as we are now exiting `XULTreeElement::GetTreeBodyFrame()`, the `kungfuDeathGrip` destructor makes the refcount for the `XULTreeElement` fall to 0, so the `XULTreeElement` is freed, along with its `nsTreeBodyFrame` (it it the case that freeing the `XULTreeElement` also frees the `nsTreeBodyFrame`? I'm not sure about that part); - we obtained a pointer to the `nsTreeBodyFrame` as a result of calling `XULTreeElement::GetTreeBodyFrame()`, but this object is now freed and poisoned; - as we try to use the poisoned object, we crash on poison value `0x7ffffffff0de7fff`. Do we perhaps need an extra `kungfuDeathGrip` in the scope of `XULTreeElement::SetFocused()`, or a way to detect that the objects were freed as we exited `XULTreeElement::GetTreeBodyFrame()`?
Another suspicious part in the code is [the `kungfuDeathGrip` in `XULTreeElement::GetTreeBodyFrame()`](https://searchfox.org/mozilla-central/source/dom/xul/XULTreeElement.cpp#84). I suppose that this is present to guarantee that the `XULTreeElement` object lives at least until the end of `XULTreeElement::GetTreeBodyFrame()`, by preventing the refcount from droping to 0 during the `doc->FlushPendingNotifications(aFlushType)` call. But what about when we come out of `XULTreeElement::GetTreeBodyFrame()`? I wonder if we could be observing the following scenario: - the `XULTreeElement` and its `nsTreeBodyFrame` are both alive and well; - `XULTreeElement::SetFocused()` calls into `XULTreeElement::GetTreeBodyFrame()`; - in `XULTreeElement::GetTreeBodyFrame()`, after `doc->FlushPendingNotifications(aFlushType);`, the refcount for the `XULTreeElement` reaches 1 as the `kungfuDeathGrip` just saved us from reaching 0; - so far the `XULTreeElement` and its `nsTreeBodyFrame` are still both alive and well; - so we are able to collect a `nsTreeBodyFrame*` (or recycle the cached one), which we will return as a result; - but as we are now exiting `XULTreeElement::GetTreeBodyFrame()`, the `kungfuDeathGrip` destructor makes the refcount for the `XULTreeElement` fall to 0, so the `XULTreeElement` is freed, along with its `nsTreeBodyFrame` (Is it the case that freeing the `XULTreeElement` also frees the `nsTreeBodyFrame`? I'm not sure about that part); - we obtained a pointer to the `nsTreeBodyFrame` as a result of calling `XULTreeElement::GetTreeBodyFrame()`, but this object is now freed and poisoned; - as we try to use the poisoned object, we crash on poison value `0x7ffffffff0de7fff`. Do we perhaps need an extra `kungfuDeathGrip` in the scope of `XULTreeElement::SetFocused()`, or a way to detect that the objects were freed as we exited `XULTreeElement::GetTreeBodyFrame()`?
Another suspicious part in the code is [the `kungfuDeathGrip` in `XULTreeElement::GetTreeBodyFrame()`](https://searchfox.org/mozilla-central/source/dom/xul/XULTreeElement.cpp#84). I suppose that this is present to guarantee that the `XULTreeElement` object lives at least until the end of `XULTreeElement::GetTreeBodyFrame()`, by preventing the refcount from droping to 0 during the `doc->FlushPendingNotifications(aFlushType)` call. But what about when we come out of `XULTreeElement::GetTreeBodyFrame()`? I wonder if we could be observing the following scenario: - the `XULTreeElement` and its `nsTreeBodyFrame` are both alive and well; - `XULTreeElement::SetFocused()` calls into `XULTreeElement::GetTreeBodyFrame()`; - in `XULTreeElement::GetTreeBodyFrame()`, after `doc->FlushPendingNotifications(aFlushType);`, the refcount for the `XULTreeElement` reaches 1 as the `kungfuDeathGrip` just saved us from reaching 0; - so far the `XULTreeElement` and its `nsTreeBodyFrame` are still both alive and well; - so we are able to collect a `nsTreeBodyFrame*` (or recycle the cached one), which we will return as a result; - but as we are now exiting `XULTreeElement::GetTreeBodyFrame()`, the `kungfuDeathGrip` destructor makes the refcount for the `XULTreeElement` fall to 0, so the `XULTreeElement` is freed, along with its `nsTreeBodyFrame` (Is it the case that freeing the `XULTreeElement` also frees the `nsTreeBodyFrame`? I'm not sure about that part); - back in `XULTreeElement::SetFocused()`, we obtained a pointer to the `nsTreeBodyFrame` object as a result of calling `XULTreeElement::GetTreeBodyFrame()`, but this object is now freed and poisoned; - as we try to use the poisoned object, we crash on poison value `0x7ffffffff0de7fff`. Do we perhaps need an extra `kungfuDeathGrip` in the scope of `XULTreeElement::SetFocused()`, or a way to detect that the objects were freed as we exited `XULTreeElement::GetTreeBodyFrame()`?