Closed
Bug 304955
Opened 19 years ago
Closed 19 years ago
Crash when scrolling through page [@ nsWindow::GetTopLevelWindow]
Categories
(Core :: Widget: Win32, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: mossop, Assigned: emaijala+moz)
References
Details
(Keywords: crash, regression, verified1.8)
Crash Data
Attachments
(1 file)
960 bytes,
patch
|
roc
:
review+
roc
:
superreview+
cbeard
:
approval1.8b4+
|
Details | Diff | Splinter Review |
Since the last couple of days, when scrolling through a large page (often
quickly) Firefox often crashes.
TB8432680E
TB8433474X
TB8439316M
Incident ID: 8432680
Stack Signature nsWindow::GetTopLevelWindow 516dabba
Product ID FirefoxTrunk
Build ID 2005081607
Trigger Time 2005-08-16 13:21:21.0
Platform Win32
Operating System Windows NT 5.1 build 2600
Module firefox.exe + (00110868)
URL visited
User Comments Scrolling
Since Last Crash 17930 sec
Total Uptime 17930 sec
Trigger Reason Access violation
Source File, Line No. c:/builds/tinderbox/Fx-
Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 8055
Stack Trace
nsWindow::GetTopLevelWindow [c:/builds/tinderbox/Fx-
Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 8055]
ChildWindow::DispatchMouseEvent [c:/builds/tinderbox/Fx-
Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 6227]
nsWindow::WindowProc [c:/builds/tinderbox/Fx-
Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsWindow.cpp, line 1429]
USER32.dll + 0x8734 (0x77d48734)
USER32.dll + 0x8816 (0x77d48816)
USER32.dll + 0x89cd (0x77d489cd)
USER32.dll + 0x8a10 (0x77d48a10)
nsAppShell::Run [c:/builds/tinderbox/Fx-
Trunk/WINNT_5.2_Depend/mozilla/widget/src/windows/nsAppShell.cpp, line 159]
nsAppStartup::Run [c:/builds/tinderbox/Fx-
Trunk/WINNT_5.2_Depend/mozilla/toolkit/components/startup/src/nsAppStartup.cpp,
line 146]
main [c:/builds/tinderbox/Fx-
Trunk/WINNT_5.2_Depend/mozilla/browser/app/nsBrowserApp.cpp, line 61]
kernel32.dll + 0x16d4f (0x7c816d4f)
Assignee: nobody → win32
Severity: normal → critical
Component: General → Widget: Win32
Product: Firefox → Core
QA Contact: general → ian
Reporter | ||
Comment 2•19 years ago
|
||
Just to say that I can reproduce this 100% of the time. Just have a page with
the scrollbar, grab it with the mouse and move up and down quickly.
Comment 3•19 years ago
|
||
Different steps to reproduce, but same stack, are in bug 304909.
Depends on: splitwindows
Summary: Crash when scrolling through page [@ nsWindow::GetTopLevelWindow] → Crash when scrolling through page [@ nsWindow::GetTopLevelWindow]
Comment 5•19 years ago
|
||
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050815 Firefox/1.0+
Testfile > 8500 lines
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/widget/src/windows/nsWindow.cpp&mark=8055&rev=#8055
Reporter | ||
Comment 6•19 years ago
|
||
Managed to crash a fresh profile with that test case in a matter of seconds
(trunk build 2005081702).
Couldn't reproduce on the latest branch build (2005081703)
Same crash for Seamonkey trunk build 2005081612 on WinXP. Try
http://www.mistral.hu/arlista_kozos.html (from bug 304837) and scroll up+down.
TB8461391Y
Reporter | ||
Comment 8•19 years ago
|
||
Installed previously nightlies and this first appears on the 14th.
Comment 9•19 years ago
|
||
can reproduce using august 17th, 2005 build.
Comment 10•19 years ago
|
||
I'm going to go ahead and say that this is unrelated to the split window work.
This is a crash in nsWindow, which is widget code, not really realted to
nsGlobalWindow, which is what was split.
No longer depends on: splitwindows
![]() |
||
Comment 11•19 years ago
|
||
So what's the regression date and time range here? That is what is the
timestamp on the last build that works and the first build that doesn't?
Flags: blocking1.8b4?
Comment 12•19 years ago
|
||
This is no. 3 on the trunk topcrashers list. This does not appear on the 1.8
branch, talkback data suggests this started on the 14th (however it maybe that
talkback has dumped any data before that date).
Hopefully that helps narrow down the regressor.
![]() |
||
Comment 13•19 years ago
|
||
The point is, Dave seems to be able to reproduce this reliably, so perhaps he
can provide precise time data here...
Reporter | ||
Comment 14•19 years ago
|
||
When I tested, it wasnt in 2005081307 and was in 2005081409. This gives these
checkins:
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-13+07%3A00&maxdate=2005-08-14+08%3A20&cvsroot=%2Fcvsroot
Bug 297561 perhaps?
I'll try doing a build with that patch backed out and see what happens.
Reporter | ||
Comment 16•19 years ago
|
||
Could not reproduce in a build from immediatly before bug 297561 but could in a
build immediatly after so thats almost certainly the culprit.
![]() |
||
Updated•19 years ago
|
Assignee: win32 → emaijala
Assignee | ||
Comment 17•19 years ago
|
||
SetMouseTrailerWindow gets called with a bogus nsWindow* in
nsWindow::DispatchMouseEvent. I found a possible culprit: GetNSWindowPtr() used
to get the window ptr is seriously flawed. It can retrieve a pointer of any
nsWindow in any process (for example a Firefox window from SeaMonkey).
Dereferencing such pointer of course doesn't work all too well. Pondering
possible solutions..
Assignee | ||
Comment 18•19 years ago
|
||
This patch adds the process ID to the property name when getting and setting
the nsWindow ptr into the property list of the native window. With this I
couldn't reproduce the crash anymore. Could someone else test it too?
Attachment #193295 -
Flags: review?(roc)
Reporter | ||
Comment 19•19 years ago
|
||
(In reply to comment #17)
> It can retrieve a pointer of any
> nsWindow in any process (for example a Firefox window from SeaMonkey).
> Dereferencing such pointer of course doesn't work all too well.
Ah, that might explain why I see the problem so much. I always have an instance
of xulrunner running with chatzilla in it.
(In reply to comment #18)
> Could someone else test it too?
Patch works for me, excellent job.
(In reply to comment #19)
> Ah, that might explain why I see the problem so much. I always have an instance
> of xulrunner running with chatzilla in it.
>
> (In reply to comment #18)
> > Could someone else test it too?
>
> Patch works for me, excellent job.
Does this also fix bug 304909?
Comment 21•19 years ago
|
||
Not sure if it's related, but I had a crash in Tbird today which might have
something in common: TB8566968X
Assignee | ||
Comment 22•19 years ago
|
||
Yes, this will probably fix bug 304909 too.
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Attachment #193295 -
Flags: superreview+
Attachment #193295 -
Flags: review?(roc)
Attachment #193295 -
Flags: review+
Assignee | ||
Comment 23•19 years ago
|
||
Comment on attachment 193295 [details] [diff] [review]
Patch v1
Checked in to trunk. Requesting approval for branch. This is needed before the
patch for bug 297561 is landed on branch.
Attachment #193295 -
Flags: approval1.8b4?
Reporter | ||
Comment 24•19 years ago
|
||
Just confirming that this now seems fixed on trunk, tested with Mozilla/5.0
(Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050822 Firefox/1.6a1
ID:2005082201.
Updated•19 years ago
|
Attachment #193295 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 25•19 years ago
|
||
Checked in to branch too.
Assignee | ||
Comment 26•19 years ago
|
||
*** Bug 304909 has been marked as a duplicate of this bug. ***
Comment 27•19 years ago
|
||
*** Bug 305031 has been marked as a duplicate of this bug. ***
http://talkback-public.mozilla.org confirms that the last build that crashed
with this stacktrace was indeed MozillaOrgMozillaTrunkWin322005082105, which
means it was fixed starting with build 2005-08-22.
Verified FIXED.
Status: RESOLVED → VERIFIED
Updated•19 years ago
|
Keywords: fixed1.8 → verified1.8
Updated•14 years ago
|
Crash Signature: [@ nsWindow::GetTopLevelWindow]
You need to log in
before you can comment on or make changes to this bug.
Description
•