Closed
Bug 50208
Opened 24 years ago
Closed 24 years ago
Crash [@ nsWindow::WindowProc ]
Categories
(SeaMonkey :: General, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: jay, Assigned: rods)
Details
(Keywords: crash, topcrash, Whiteboard: [rtm++]reviewer,superreviewer)
Crash Data
Attachments
(1 file)
984 bytes,
patch
|
Details | Diff | Splinter Review |
No specific steps to reproduce are given in the talkback data, but this is a top crasher on Win98 and Win95 at startup. The stack trace is below along with some entries. I am unable to reproduce this crash. CVS blame shows pinkerton at nsWindows.cpp, line 815...so adding him to cc list. Incident ID 16205833 nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 815] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x242e7 (0xbff942e7) nsWindow::WindowProc e25a5634 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/windows/nsWindow. cpp line 815 Build: 2000080712 CrashDate: 2000-08-24 UptimeMinutes: 396 Total: 1407 OS: Windows 98 4.10 build 67766446 URL: Comment: Failed during start up. Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=16234225 nsWindow::WindowProc e25a5634 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/windows/nsWindow. cpp line 815 Build: 2000080712 CrashDate: 2000-08-23 UptimeMinutes: 0 Total: 174 OS: Windows 98 4.10 build 67766446 URL: Comment: Doing nothing just clicked on icon to get Netscape 6 started. Stacktrace: http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=16216971
Reporter | ||
Comment 1•24 years ago
|
||
adding topcrash keyword. [@ nsWindow::WindowProc ]
Keywords: topcrash
Comment 3•24 years ago
|
||
*shrug*
Comment 4•24 years ago
|
||
ok, perhaps people did not uninstall pr1 (how could they? no option) and this caused corruption? Often, such crashes are due to profile corruptions as well (a lot changed from pr1 to pr2)
Reporter | ||
Comment 5•24 years ago
|
||
Just for the record, this is back for latest branch builds. Here are the latest entries: nsWindow::WindowProc Stack Trace: nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp line 936] KERNEL32.DLL + 0x363b (0xbff7363b) KERNEL32.DLL + 0x24407 (0xbff94407) nsWindow::WindowProc e25a5634 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/windows/nsWindow. cpp line 936 Build: 2000100409 CrashDate: 2000-10-04 UptimeMinutes: 40 Total: 40 OS: Windows 98 4.10 build 67766446 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18521009 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18521009 nsWindow::WindowProc e25a5634 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/windows/nsWindow. cpp line 936 Build: 2000100409 CrashDate: 2000-10-04 UptimeMinutes: 3 Total: 43 OS: Windows 98 4.10 build 67766446 URL: Comment: See bugzilla 39573 Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18521273 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18521273 nsWindow::WindowProc 4577858c http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/windows/nsWindow. cpp line 936 Build: 2000100309 CrashDate: 2000-10-04 UptimeMinutes: 609 Total: 609 OS: Windows 98 4.90 build 73010104 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18502400 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18502400 nsWindow::WindowProc e25a5634 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/widget/src/windows/nsWindow. cpp line 936 Build: 2000100609 CrashDate: 2000-10-07 UptimeMinutes: 580 Total: 580 OS: Windows 98 4.10 build 67766446 URL: Comment: Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18689928 StackTrace: http://climate/reports/stackcommentemail.cfm?dynamicBBID=18689928 NOTE: One of the entries mention bug 39573.
Summary: PR2 Topcrash [@ nsWindow::WindowProc ] → Crash [@ nsWindow::WindowProc ]
Comment 6•24 years ago
|
||
nominate rtm, mark rtm need info. since chofmann's on sabbatical we need someone else to look at this more closely.
Keywords: rtm
Whiteboard: [rtm need info] need engineer to take a deeper look
Comment 7•24 years ago
|
||
all crashes are in a netscape internal url. What service is this? does it exist outside of netscape?
Comment 8•24 years ago
|
||
adding danm & kmcclusk since they've been hacking around in there as well. A query on climate shows this is still happening both in PR3 and on the branch. doron - all these URLs point to servers inside netscape, but are not the URL the crashes are on, just URLS for netscape talkback reports and bonsai (cvs blame).
Comment 9•24 years ago
|
||
Right after the call to: nsWindow *someWindow = GetNSWindowPtr(hWnd); at line 931 nsWindow.cpp I think we should try adding a check for a null someWindow and return the result of the default window handler. if (nsnull == someWindow) return ::DefWindowProc(hWnd, msg, wParam, lParam); The nsWindow::OnDestroy method resets the pointer to the nsIWidget instance to null, so it's possible that after the OnDestroy is called we are getting a message for the window which results in a null someWindow.
Comment 10•24 years ago
|
||
Of course in theory we shouldn't even be in our windowproc unless the window is currently subclassed, which it shouldn't be outside of OnDestroy and StandardWindowCreate. And of course no one here can reproduce the bug. My personal take on this, also unlikely to be true, is that maybe-just-maybe a message is sneaking in for the window early on during its creation, between the line where we take its windowproc and hook up its (nsWindow *) property so GetNSWindowPtr will work. I think those two lines are done out of order in SubclassWindow, so I'd recommend this patch --- ./widget/src/windows/nsWindow.cpp.3.295 Mon Oct 16 19:59:03 2000 +++ ./widget/src/windows/nsWindow.cpp Mon Oct 16 19:58:37 2000 @@ -3555,12 +3555,12 @@ NS_PRECONDITION(::IsWindow(mWnd), "Invalid window handle"); if (bState) { + // connect the this pointer to the nsWindow handle + SetNSWindowPtr(mWnd, this); // change the nsWindow proc mPrevWndProc = (WNDPROC)::SetWindowLong(mWnd, GWL_WNDPROC, (LONG)nsWindow::WindowProc); NS_ASSERTION(mPrevWndProc, "Null standard window procedure"); - // connect the this pointer to the nsWindow handle - SetNSWindowPtr(mWnd, this); } else { ::SetWindowLong(mWnd, GWL_WNDPROC, (LONG)mPrevWndProc); on the offhand chance that some message is sneaking in right there. I can't say that I have a great deal of confidence that this is the right fix, either. Point in support: on the day this bug was filed, 24 Aug, the build in use was probably using nsWindow.cpp version 3.289. Line 815 of that file points to some pretty unlikely line in the function DealWithPopups.
Comment 11•24 years ago
|
||
ok, thanks for taking a look at this one. doesn't sound like we have a good handle on the problem or the fix, so I'm rtm- for now, and we can play with this post-RTM. kmcclusk/danm: can one of you guys take this bug over from chofmann since I doubt he's the right person to own it?
Whiteboard: [rtm need info] need engineer to take a deeper look → [rtm-]
Comment 12•24 years ago
|
||
Oh heck. We're all working in the dark because no one can duplicate it, but Kevin and I have both posted simple, harmless patches that may address the issue, judging from what we can tell in the talkback reports. This is a top crasher. It deserves a shot, as best as we can. In a sane development environment we'd simply check them in and hope they helped. Marking rtm+ in the vague hopes that we can get these changes past micromanagement, but I promise to leave it minused if someone comes along and reminuses.
Whiteboard: [rtm-] → [rtm+]
Assignee | ||
Comment 14•24 years ago
|
||
*** Bug 51174 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 15•24 years ago
|
||
Assignee | ||
Comment 16•24 years ago
|
||
With this patch we are now hitting the assert and preventing the crash. We will research for the cause of the assert under bug 51174. Bugs 50208 and 51174 have the same stack trace.
Status: NEW → ASSIGNED
Comment 17•24 years ago
|
||
Patch looks good. Simple, low risk check for null pointer. r=kmcclusk@netscape.com
Comment 18•24 years ago
|
||
a=buster
Comment 19•24 years ago
|
||
when I've seen this stack before, it's because the nsWindow has been destroyed, but doesn't really know it yet (i haven't been able to determine why). As a result, its data members are a crapshoot and are probably mostly random. I suspect we're getting lucky if the hWnd is NULL and we shouldn't rely on it.
Comment 20•24 years ago
|
||
The patch doesn't rely on the nsWindow pointer being valid. Instead, It relies on the ptr being stored with the native window being null. The nsWindow instance should have set this pointer (stored on native window) to null when it was destroyed.
Assignee | ||
Comment 21•24 years ago
|
||
checked into trunk
Whiteboard: [rtm+] → [rtm+]reviewer,superreviewer
Comment 22•24 years ago
|
||
rtm++
Whiteboard: [rtm+]reviewer,superreviewer → [rtm++]reviewer,superreviewer
Assignee | ||
Updated•24 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 23•24 years ago
|
||
checked into branch
Comment 24•24 years ago
|
||
is there a way for me to verify this fixed? jpatel - any recent talkback reports from this? lchiang wants all rtm++ bugs verified and I have no idea how to do this one.
Comment 25•24 years ago
|
||
This crash is not visible in the Talkback Topcrash Reports.
Comment 26•24 years ago
|
||
cc: lchiang. Lisa: is it enough that this crash is not showing up anymore for this to get verified?
Comment 27•24 years ago
|
||
Yes, doron, that is good enough for this case. We never had reproducible steps and had a lot of talkback reports on this. This trace no longer shows up in talkback topcrash. So, will mark verified.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•13 years ago
|
Crash Signature: [@ nsWindow::WindowProc ]
You need to log in
before you can comment on or make changes to this bug.
Description
•