Closed
Bug 531069
Opened 15 years ago
Closed 12 years ago
Firefox 3.6b1 Crash Report [@ do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*() ]
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
INCOMPLETE
Tracking | Status | |
---|---|---|
status1.9.1 | --- | wanted |
People
(Reporter: MatsPalmgren_bugz, 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
Reporter | ||
Updated•15 years ago
|
Whiteboard: [sg:dos (critical w/out frame-poisoning)]
Reporter | ||
Comment 1•15 years ago
|
||
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?
Reporter | ||
Comment 2•15 years ago
|
||
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-
Comment 4•15 years ago
|
||
Do we even know this crash affects the 1.9.1 branch?
Comment 5•15 years ago
|
||
(Dan also meant to ask about 1.9.0.)
Flags: wanted1.9.0.x?
Flags: blocking1.9.0.17?
Reporter | ||
Comment 6•15 years ago
|
||
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.
Updated•15 years ago
|
blocking1.9.1: --- → ?
Flags: blocking1.9.0.17?
Updated•15 years ago
|
Summary: Firefox 3.6b1 Crash Report [ @do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*() ] → Firefox 3.6b1 Crash Report [@ do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*() ]
Updated•14 years ago
|
Keywords: testcase-wanted
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ do_QueryFrame::operator<nsIScrollableFrame> nsIScrollableFrame*() ]
Comment 7•12 years ago
|
||
I don't think we know enough to fix anything here
Group: core-security
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Updated•9 years ago
|
Keywords: testcase-wanted
You need to log in
before you can comment on or make changes to this bug.
Description
•