Closed Bug 304955 Opened 17 years ago Closed 17 years ago

Crash when scrolling through page [@ nsWindow::GetTopLevelWindow]

Categories

(Core :: Widget: Win32, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: mossop, Assigned: emaijala+moz)

References

Details

(Keywords: crash, regression, verified1.8)

Crash Data

Attachments

(1 file)

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
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.
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]
seems to be only an XP issue, can't reproduce on win2k
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
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
Installed previously nightlies and this first appears on the 14th.
can reproduce using august 17th, 2005 build.
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
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?
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.
The point is, Dave seems to be able to reproduce this reliably, so perhaps he
can provide precise time data here...
Yeah, that could have done it...  ere, roc, any ideas here?
Blocks: 297561
Could not reproduce in a build from immediatly before bug 297561 but could in a
build immediatly after so thats almost certainly the culprit.
Assignee: win32 → emaijala
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..
Attached patch Patch v1Splinter Review
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)
(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?

Not sure if it's related, but I had a crash in Tbird today which might have
something in common: TB8566968X
Blocks: 304909
Yes, this will probably fix bug 304909 too.
Flags: blocking1.8b4? → blocking1.8b4+
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?
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.
Attachment #193295 - Flags: approval1.8b4? → approval1.8b4+
Checked in to branch too.
Status: NEW → RESOLVED
Closed: 17 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
*** Bug 304909 has been marked as a duplicate of this bug. ***
*** 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
Keywords: fixed1.8verified1.8
Crash Signature: [@ nsWindow::GetTopLevelWindow]
You need to log in before you can comment on or make changes to this bug.