Closed Bug 50208 Opened 24 years ago Closed 24 years ago

Crash [@ nsWindow::WindowProc ]

Categories

(SeaMonkey :: General, defect, P1)

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jay, Assigned: rods)

Details

(Keywords: crash, topcrash, Whiteboard: [rtm++]reviewer,superreviewer)

Crash Data

Attachments

(1 file)

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
adding topcrash keyword.  [@ nsWindow::WindowProc ]
Keywords: topcrash
Adding crash keyword
Keywords: crash
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)
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 ]
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
all crashes are in a netscape internal url.  What service is this? does it exist
outside of netscape?
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).
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.
  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.
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-]
  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+]
taking bug
Assignee: chofmann → rods
Priority: P3 → P1
*** Bug 51174 has been marked as a duplicate of this bug. ***
Attached patch patchSplinter Review
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
Patch looks good. Simple, low risk check for null pointer.
r=kmcclusk@netscape.com
a=buster
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.
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. 
checked into trunk
Whiteboard: [rtm+] → [rtm+]reviewer,superreviewer
rtm++
Whiteboard: [rtm+]reviewer,superreviewer → [rtm++]reviewer,superreviewer
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
checked into branch
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.
This crash is not visible in the Talkback Topcrash Reports.
cc: lchiang. Lisa: is it enough that this crash is not showing up anymore for
this to get verified?
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
Product: Browser → Seamonkey
Crash Signature: [@ nsWindow::WindowProc ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: