Bugzilla

(In reply to Timothy Nikkel (:tnikkel) from comment #30)
> If the memory got reallocated then the crash signature might be different, we'd get function names from the vtable of the new object. There was another crash where we saw this happen recently with nsMenuPopupFrame functions showing up in an impossible place. Or if it was a new object of the same type the code would potentially just not crash.

I didn't find other crash signatures of significant volume where the proto signature would contain, say, `mozilla::dom::XULTreeElement_Binding::set_focused`. But, indeed, we could just be not crashing, and allocating from this `PresShell` arena is probably much less common than the usual paths for allocation.

Reading your comment made me wonder if we could find additional hints in other crash signatures. For example, where do Nightly and early beta users crash here, since we do not have reports from them like [:emilio] mentioned in comment 7?

I think the following signatures look interesting:

- [`mozilla::PresShell::DoFlushPendingNotifications`](https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3APresShell%3A%3ADoFlushPendingNotifications): This signature is often reached through crashing on `MOZ_DIAGNOSTIC_ASSERT(!mForbiddenToFlush) (This is bad!)`. Nightly and early beta users could be crashing here. One user comment mentions trying to delete a lot of history lines then using Firefox during deletion (e.g. switching tabs), and [their crash stack](https://crash-stats.mozilla.org/report/index/ca497291-92bd-4299-b70b-45c280230515) seems very interesting, it goes from `nsNavHistoryResult::OnVisit` to `nsTreeSelection::FireOnSelectHandler`, `mozilla::dom::XULElement_Binding::focus`, `mozilla::PresShell::DoFlushPendingNotifications`, `nsTreeBodyFrame::DestroyFrom`, `mozilla::dom::XULTreeElement_Binding::endUpdateBatch`, `mozilla::PresShell::DoFlushPendingNotifications` (flushing reentrancy related to navigation history with `nsTreeBodyFrame` and `XULTreeElement` involved);
- [`nsCycleCollectingAutoRefCnt::incr`](https://crash-stats.mozilla.org/signature/?signature=nsCycleCollectingAutoRefCnt%3A%3Aincr): This signature is another late beta / release crash where user comments talk about deleting a lot of old navigation history e.g. [here](https://crash-stats.mozilla.org/report/index/14b5b0a0-ad36-403f-9edf-2f9130230509) and [here](https://crash-stats.mozilla.org/report/index/b0d06d38-7b20-4c8d-b1dd-31d030230422). It seems like it could be a variation of the other crash with potentially the same root cause. It occurs through `mozilla::dom::XULTreeElement_Binding::get_columns` instead of `mozilla::dom::XULTreeElement_Binding::set_focused`.

Note: Both signatures also contain crashes which do not seem related to this bug. But a big proportion seems related in both.

(In reply to Timothy Nikkel (:tnikkel) from comment #30)
> If the memory got reallocated then the crash signature might be different, we'd get function names from the vtable of the new object. There was another crash where we saw this happen recently with nsMenuPopupFrame functions showing up in an impossible place. Or if it was a new object of the same type the code would potentially just not crash.

I didn't find other crash signatures of significant volume where the proto signature would contain, say, `mozilla::dom::XULTreeElement_Binding::set_focused`. But, indeed, we could just be not crashing, also allocating from this `PresShell` arena is probably much less common than the usual paths for allocation.

Reading your comment made me wonder if we could find additional hints in other crash signatures. For example, where do Nightly and early beta users crash here, since we do not have reports from them like [:emilio] mentioned in comment 7?

I think the following signatures look interesting:

- [`mozilla::PresShell::DoFlushPendingNotifications`](https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3APresShell%3A%3ADoFlushPendingNotifications): This signature is often reached through crashing on `MOZ_DIAGNOSTIC_ASSERT(!mForbiddenToFlush) (This is bad!)`. Nightly and early beta users could be crashing here. One user comment mentions trying to delete a lot of history lines then using Firefox during deletion (e.g. switching tabs), and [their crash stack](https://crash-stats.mozilla.org/report/index/ca497291-92bd-4299-b70b-45c280230515) seems very interesting, it goes from `nsNavHistoryResult::OnVisit` to `nsTreeSelection::FireOnSelectHandler`, `mozilla::dom::XULElement_Binding::focus`, `mozilla::PresShell::DoFlushPendingNotifications`, `nsTreeBodyFrame::DestroyFrom`, `mozilla::dom::XULTreeElement_Binding::endUpdateBatch`, `mozilla::PresShell::DoFlushPendingNotifications` (flushing reentrancy related to navigation history with `nsTreeBodyFrame` and `XULTreeElement` involved);
- [`nsCycleCollectingAutoRefCnt::incr`](https://crash-stats.mozilla.org/signature/?signature=nsCycleCollectingAutoRefCnt%3A%3Aincr): This signature is another late beta / release crash where user comments talk about deleting a lot of old navigation history e.g. [here](https://crash-stats.mozilla.org/report/index/14b5b0a0-ad36-403f-9edf-2f9130230509) and [here](https://crash-stats.mozilla.org/report/index/b0d06d38-7b20-4c8d-b1dd-31d030230422). It seems like it could be a variation of the other crash with potentially the same root cause. It occurs through `mozilla::dom::XULTreeElement_Binding::get_columns` instead of `mozilla::dom::XULTreeElement_Binding::set_focused`.

Note: Both signatures also contain crashes which do not seem related to this bug. But a big proportion seems related in both.

(In reply to Timothy Nikkel (:tnikkel) from comment #30)
> If the memory got reallocated then the crash signature might be different, we'd get function names from the vtable of the new object. There was another crash where we saw this happen recently with nsMenuPopupFrame functions showing up in an impossible place. Or if it was a new object of the same type the code would potentially just not crash.

I didn't find other crash signatures of significant volume where the proto signature would contain, say, `mozilla::dom::XULTreeElement_Binding::set_focused`. But, indeed, we could just be not crashing, also allocating from this `PresShell` arena is probably much less common than the usual paths for allocation.

Reading your comment made me wonder if we could find additional hints in other crash signatures. For example, where do Nightly and early beta users crash here, since we do not have reports from them like [:emilio] mentioned in comment 7?

I think the following signatures look interesting:

- [`mozilla::PresShell::DoFlushPendingNotifications`](https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3APresShell%3A%3ADoFlushPendingNotifications): This signature is often reached through crashing on `MOZ_DIAGNOSTIC_ASSERT(!mForbiddenToFlush) (This is bad!)`. Nightly and early beta users could be crashing here. One user comment mentions trying to delete a lot of history lines then using Firefox during deletion (e.g. switching tabs), and [their crash stack](https://crash-stats.mozilla.org/report/index/ca497291-92bd-4299-b70b-45c280230515) seems very interesting, it goes from `nsNavHistoryResult::OnVisit` to `nsTreeSelection::FireOnSelectHandler`, `mozilla::dom::XULElement_Binding::focus`, `mozilla::PresShell::DoFlushPendingNotifications`, `nsTreeBodyFrame::DestroyFrom`, `mozilla::dom::XULTreeElement_Binding::endUpdateBatch`, `mozilla::PresShell::DoFlushPendingNotifications` (flushing reentrancy related to navigation history with `nsTreeBodyFrame` and `XULTreeElement` involved);
- [`nsCycleCollectingAutoRefCnt::incr`](https://crash-stats.mozilla.org/signature/?signature=nsCycleCollectingAutoRefCnt%3A%3Aincr): This signature contains another late beta / release crash where user comments talk about deleting a lot of old navigation history e.g. [here](https://crash-stats.mozilla.org/report/index/14b5b0a0-ad36-403f-9edf-2f9130230509) and [here](https://crash-stats.mozilla.org/report/index/b0d06d38-7b20-4c8d-b1dd-31d030230422). It seems like it could be a variation of the other crash with potentially the same root cause. It occurs through `mozilla::dom::XULTreeElement_Binding::get_columns` instead of `mozilla::dom::XULTreeElement_Binding::set_focused`.

Note: Both signatures also contain crashes which do not seem related to this bug. But a big proportion seems related in both.

(In reply to Timothy Nikkel (:tnikkel) from comment #30)
> If the memory got reallocated then the crash signature might be different, we'd get function names from the vtable of the new object. There was another crash where we saw this happen recently with nsMenuPopupFrame functions showing up in an impossible place. Or if it was a new object of the same type the code would potentially just not crash.

I didn't find other crash signatures of significant volume where the proto signature would contain, say, `mozilla::dom::XULTreeElement_Binding::set_focused`. But, indeed, we could just be not crashing, also allocating from this `PresShell` arena is probably much less common than the usual paths for allocation.

Reading your comment made me wonder if we could find additional hints in other crash signatures. For example, where do Nightly and early beta users crash here, since we do not have reports from them like [:emilio] mentioned in comment 7?

I think the following signatures look interesting:

- [`mozilla::PresShell::DoFlushPendingNotifications`](https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3APresShell%3A%3ADoFlushPendingNotifications): This signature is often reached through crashing on `MOZ_DIAGNOSTIC_ASSERT(!mForbiddenToFlush) (This is bad!)`. Nightly and early beta users could be crashing here. One user comment mentions trying to delete a lot of history lines then using Firefox during deletion (e.g. switching tabs), and [their crash stack](https://crash-stats.mozilla.org/report/index/ca497291-92bd-4299-b70b-45c280230515) seems very interesting, it goes from `nsNavHistoryResult::OnVisit` to `nsTreeSelection::FireOnSelectHandler`, `mozilla::dom::XULElement_Binding::focus`, `mozilla::PresShell::DoFlushPendingNotifications`, `nsTreeBodyFrame::DestroyFrom`, `mozilla::dom::XULTreeElement_Binding::endUpdateBatch`, `mozilla::PresShell::DoFlushPendingNotifications` (flushing reentrancy related to navigation history with `nsTreeBodyFrame` and `XULTreeElement` involved);
- [`nsCycleCollectingAutoRefCnt::incr`](https://crash-stats.mozilla.org/signature/?signature=nsCycleCollectingAutoRefCnt%3A%3Aincr): This signature contains another late beta / release crash where user comments talk about deleting a lot of old navigation history e.g. [here](https://crash-stats.mozilla.org/report/index/14b5b0a0-ad36-403f-9edf-2f9130230509) and [here](https://crash-stats.mozilla.org/report/index/b0d06d38-7b20-4c8d-b1dd-31d030230422). It seems like it could be a variation of the other crash with potentially the same root cause. It occurs through `mozilla::dom::XULTreeElement_Binding::get_columns` instead of `mozilla::dom::XULTreeElement_Binding::set_focused`.

Note: Both signatures also contain crashes which do not seem related to this bug, especially for the second signature where there are many different proto signatures. But a proportion seems related in both.