Closed Bug 531069 Opened 11 years ago Closed 9 years ago

Firefox 3.6b1 Crash Report [@ do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*() ]

Categories

(Core :: Layout, defect)

1.9.2 Branch
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
status1.9.1 --- wanted

People

(Reporter: mats, Unassigned)

Details

(Keywords: crash, Whiteboard: [sg:dos null deref])

Crash Data

This bug is spawned off from bug 526769 comment 17.

Firefox 3.6b1 Crash Report [ @do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*() ]

bp-f8b3ef8c-a802-4915-a9b3-5f7eb2091101

do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*	 layout/generic/nsQueryFrame.h:278
ViewportFrame::AdjustReflowStateForScrollbars	layout/generic/nsViewportFrame.cpp:229
ViewportFrame::Reflow	layout/generic/nsViewportFrame.cpp:307
PresShell::DoReflow	layout/base/nsPresShell.cpp:7208
PresShell::ProcessReflowCommands	layout/base/nsPresShell.cpp:7341
PresShell::FlushPendingNotifications	layout/base/nsPresShell.cpp:4871
_MD_CURRENT_THREAD	nsprpub/pr/src/md/windows/w95thred.c:308
PresShell::ReflowEvent::Run	layout/base/nsPresShell.cpp:7018
nsThread::ProcessNextEvent	xpcom/threads/nsThread.cpp:527
nsBaseAppShell::Run	widget/src/xpwidgets/nsBaseAppShell.cpp:170
nsAppStartup::Run	toolkit/components/startup/src/nsAppStartup.cpp:182
PR_GetEnv	
wmain	toolkit/xre/nsWindowsWMain.cpp:110
__tmainCRTStartup	obj-firefox/memory/jemalloc/crtsrc/crtexe.c:591
BaseProcessStart
Whiteboard: [sg:dos (critical w/out frame-poisoning)]
BTW, the above crash was the only one in the past 4 weeks at this date
(for 1.9.2 or older, the trunk crashes are bug 526769).
blocking1.9.1: --- → ?
status1.9.1: --- → ?
Flags: wanted1.9.0.x?
Flags: blocking1.9.2?
Flags: blocking1.9.0.17?
The crash address here is 0x0, so it's not a frame poisoning crash.
No longer blocks: PoisonFrameCrash
Whiteboard: [sg:dos (critical w/out frame-poisoning)] → [sg:dos]
do_QueryFrame(kidFrame) handles the case where kidFrame is null, so that's not the problem. I have no idea what the problem might be. I don't think we should block on a single crash, though.
Flags: blocking1.9.2? → blocking1.9.2-
Do we even know this crash affects the 1.9.1 branch?
blocking1.9.1: ? → ---
status1.9.1: ? → ---
Whiteboard: [sg:dos] → [sg:dos null deref]
(Dan also meant to ask about 1.9.0.)
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.17?
Those branches does not have do_QueryFrame, so the top stack frame
would be something different (possibly do_QueryInterface).
The best would be to search for ViewportFrame::AdjustReflowStateForScrollbars
or ViewportFrame::Reflow in the stack *somewhere*, but unfortunately Socorro
dropped that feature (bug 480503).

Querying for top stack frame only, I found:
For 1.9.0: bp-e7211f34-2663-4c65-874d-b8fbb2091126
For 1.9.1: bp-17dc5b2b-c817-4072-8033-8201e2091122
For 1.9.2 (3.6b2): bp-17178c36-b016-40c7-a03d-888ae2091122
These look like they are the same crash.
The last one has crash address 0xffffffffcccccccc so it might be more
serious than a null deref.
blocking1.9.1: --- → ?
Flags: blocking1.9.0.17?
blocking1.9.1: ? → ---
Flags: blocking1.9.0.17? → wanted1.9.0.x+
Summary: Firefox 3.6b1 Crash Report [ @do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*() ] → Firefox 3.6b1 Crash Report [@ do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*() ]
Crash Signature: [@ do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*() ]
I don't think we know enough to fix anything here
Group: core-security
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.