Crash [@ nsWindow::WindowProc ]



19 years ago
14 years ago


(Reporter: jay, Assigned: rods)


({crash, topcrash})

crash, topcrash

Firefox Tracking Flags

(Not tracked)


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


(1 attachment)



19 years ago
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 adding him to cc list.

Incident ID 16205833 
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 815] 
KERNEL32.DLL + 0x363b (0xbff7363b) 
KERNEL32.DLL + 0x242e7 (0xbff942e7) 

nsWindow::WindowProc e25a5634
cpp line 815
        Build: 2000080712 CrashDate: 2000-08-24 UptimeMinutes: 396  Total: 1407 
        OS: Windows 98  4.10 build 67766446
        Comment: Failed during start up.

nsWindow::WindowProc e25a5634
cpp line 815
        Build: 2000080712 CrashDate: 2000-08-23 UptimeMinutes: 0  Total: 174 
        OS: Windows 98  4.10 build 67766446
        Comment: Doing nothing just clicked on icon to get Netscape 6 started.

Comment 1

19 years ago
adding topcrash keyword.  [@ nsWindow::WindowProc ]
Keywords: topcrash

Comment 2

19 years ago
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)

Comment 5

19 years ago
Just for the record, this is back for latest branch builds.  Here are the latest 

Stack Trace: 

[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp  line 936] 
         KERNEL32.DLL + 0x363b (0xbff7363b)  
         KERNEL32.DLL + 0x24407 (0xbff94407)  
    nsWindow::WindowProc e25a5634
cpp line 936
        Build: 2000100409 CrashDate: 2000-10-04 UptimeMinutes: 40  Total: 40 
        OS: Windows 98  4.10 build 67766446
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18521009

    nsWindow::WindowProc e25a5634
cpp line 936
        Build: 2000100409 CrashDate: 2000-10-04 UptimeMinutes: 3  Total: 43 
        OS: Windows 98  4.10 build 67766446
        Comment: See bugzilla 39573
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18521273

    nsWindow::WindowProc 4577858c
cpp line 936
        Build: 2000100309 CrashDate: 2000-10-04 UptimeMinutes: 609  Total: 609 
        OS: Windows 98  4.90 build 73010104
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18502400

    nsWindow::WindowProc e25a5634
cpp line 936
        Build: 2000100609 CrashDate: 2000-10-07 UptimeMinutes: 580  Total: 580 
        OS: Windows 98  4.10 build 67766446
         Detailed : http://climate/reports/incidenttemplate.cfm?bbid=18689928

NOTE: One of the entries mention bug 39573.
Summary: PR2 Topcrash [@ nsWindow::WindowProc ] → Crash [@ nsWindow::WindowProc ]

Comment 6

19 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
all crashes are in a netscape internal url.  What service is this? does it exist
outside of netscape?

Comment 8

19 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).
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

19 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, 
         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

19 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

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

19 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+]

Comment 13

19 years ago
taking bug
Assignee: chofmann → rods
Priority: P3 → P1

Comment 14

19 years ago
*** Bug 51174 has been marked as a duplicate of this bug. ***

Comment 15

19 years ago
Created attachment 17452 [details] [diff] [review]

Comment 16

19 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.
Patch looks good. Simple, low risk check for null pointer.

Comment 18

19 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.
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

Comment 21

19 years ago
checked into trunk
Whiteboard: [rtm+] → [rtm+]reviewer,superreviewer

Comment 22

19 years ago
Whiteboard: [rtm+]reviewer,superreviewer → [rtm++]reviewer,superreviewer


19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 23

19 years ago
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?

Comment 27

19 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.
Product: Browser → Seamonkey
Crash Signature: [@ nsWindow::WindowProc ]
You need to log in before you can comment on or make changes to this bug.