spin off of bug 526587 new crashes resulting from frame poisoning reports at http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6a1&version=Firefox%3A3.6a1pre&version=Firefox%3A3.6a2pre&version=Firefox%3A3.6b1&version=Firefox%3A3.6b1pre&version=Firefox%3A3.6b2pre&version=Firefox%3A3.7a1pre&query_search=signature&query_type=exact&query=nsIFrame%3A%3AGetClosestView%28nsPoint*%29&date=&range_value=4&range_unit=weeks&do_query=1&signature=nsIFrame%3A%3AGetClosestView%28nsPoint*%29 example stack at Frame Module Signature [Expand] Source 0 xul.dll nsIFrame::GetClosestView layout/generic/nsFrame.cpp:5424 1 xul.dll nsView::~nsView view/src/nsView.cpp:213 2 xul.dll nsView::`scalar deleting destructor' 3 xul.dll nsContainerFrame::Destroy layout/generic/nsContainerFrame.cpp:310 there is a similar signature on 3.5.x and older releases that may or may not be the same problem you can see those reporters in this more general query http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=nsIFrame%3A%3AGetClosestView%28nsPoint*%29&date=&range_value=4&range_unit=weeks&do_query=1&signature=nsIFrame%3A%3AGetClosestView%28nsPoint*%29

There's two different crashes going on here. * In 3.6b2, http://crash-stats.mozilla.com/report/index/ecfe579d-344d-4eb4-b39e-688b92091112 with this stack: nsIFrame::GetClosestView layout/generic/nsFrame.cpp:5471 nsIFrame::GetWindow layout/generic/nsFrame.cpp:3613 [nsAccessNode::GetFrame inlined into below] nsAccessibleWrap::GetHWNDFor accessible/src/msaa/nsAccessibleWrap.cpp:1750 It appears that nsIFrame::GetClosestView is being called with a poisoned 'this' pointer (sure would be nice if minidumps included the registers...) and naturally enough, crashes immediately. The frame pointer is coming from nsIPresShell::GetPrimaryFrameFor, called by nsAccessNode on its content node. * In 3.7 nightlies, with the stack quoted in the original report. This stack only makes sense if I assume that the compiler managed to inline nsPresShell::ClearMouseCapture *through the nsIViewObserver abstract interface* into nsView::DropMouseGrabbing and thence into the nsView destructor, but it's the same deal. The bad frame comes from GetPrimaryFrameFor on a content node. So, this looks to me like both of these are manifestations of a circumstance where a frame somehow gets deleted without being removed from the primary frame map, which points at the frame constructor. Boris, any thoughts?

Minidumps do include the registers. > The frame pointer is coming from nsIPresShell::GetPrimaryFrameFor, called by > nsAccessNode on its content node. That sounds bad. Difficult to track down without steps to reproduce. Can you try enabling accessibility (e.g. in GNOME system prefs) and try some of the URLs in comment #1? > the compiler managed to inline nsPresShell::ClearMouseCapture *through the > nsIViewObserver abstract interface* into nsView::DropMouseGrabbing Yes, MSVC PGO can do that.

There are basically two ways GetPrimaryFrameFor might end up returning bogus things: 1) Frame destruction didn't remove the frame (or some other frame) from the primary frame map. 2) The frame was somehow readded to the primary frame map during destruction, after being removed. It's hard to say which is going on here. :( One could hope fantasai's changes to frame destruction would help, though.

(In reply to comment #3) > Minidumps do include the registers. > > > The frame pointer is coming from nsIPresShell::GetPrimaryFrameFor, called by > > nsAccessNode on its content node. > > That sounds bad. Difficult to track down without steps to reproduce. Can you > try enabling accessibility (e.g. in GNOME system prefs) and try some of the > URLs in comment #1? I tried that among a bunch of other things and wasn't able to make it crash. I note that the crash reports list a lot of weird extensions - 3.6b2 mozilla_cc@internetdownloadmanager.com 6.3 {972ce4c6-7e08-4474-a285-3208198ce6fd} 3.6b2 3.7pre smarterwiki@wikiatic.com 2.1.4 {46551EC9-40F0-4e47-8E18-8E5CF550CFB8} 1.0.6 {8620c15f-30dc-4dba-a131-7c5d20cf4a29} 2.0.2 {20a82645-c095-46ed-80e3-08825760534b} 1.1 StrataHomeTab@ReduxTeam 0.0.2 tabprogressbar@studio17.wordpress.com 0.6 {972ce4c6-7e08-4474-a285-3208198ce6fd} 3.7a1pre Strata40@SpewBoy.au 0.4.3

Also, a lot of those URLs require a login before they'll do anything interesting, or they show me *my* Facebook page or Google calendar, which isn't going to help...

Still exists - a handful in 8.0 and 7.0.1. Realistically, this isn't going to get fixed since it's so low volume. Resolving as won't fix to focus efforts on higher volume crashes.