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•13 years ago
|
Crash Signature: [@ nsWindow::GetTopLevelWindow]
You need to log in
before you can comment on or make changes to this bug.
Description
•