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()`, 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()`?
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()`?

Back to Bug 1809492 Comment 27