170693 - moz crashes randomly opening a new window [@ nsWindowWatcher::GetActiveWindow ]

Status: RESOLVED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[Mrten]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20020923
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2b) Gecko/20020923

since 21/9 i've been experiencing random crashes, but usually when the opening a
new window. latest talkback ID is:

TB11522883Q



Reproducible: Sometimes

Steps to Reproduce:
1. ..
2.
3.

Comment 1

[Mrten]

adding stephend for talkback retrieval please?
(TB11522883Q)

btw, stephend, is this the "correct" way to retrieve TB-info?

isn't there another way so that i don't have to bug you and/or don't have to
file a probable duplicate bug?

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

A better way is just to File | Send Page from the browser, instead of cc:ing me
on it.

nsWindowWatcher::GetActiveWindow
[c:/builds/seamonkey/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,
line 864]
invoke_copy_to_stack
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp]
XPCWrappedNative::CallMethod
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 1996]
XPC_WN_GetterSetter
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1299]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 830]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 926]
js_GetProperty [c:/builds/seamonkey/mozilla/js/src/jsobj.c, line 2547]
js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2640]
js_Invoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 841]
js_InternalInvoke [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 926]
JS_CallFunctionValue [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3433]
nsJSContext::CallEventHandler
[c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1044]
GlobalWindowImpl::RunTimeout
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 4605]
GlobalWindowImpl::InsertTimeoutIntoList
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 4941]
destroyTimerEvent [c:/builds/seamonkey/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 436]
nsAppShell::GetNativeEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsAppShell.cpp, line 233]
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 472]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1524]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1872]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1892]
Mozilla.exe + 0x7992 (0x00407992)
KERNEL32.dll + 0x1bbb5 (0x77f1bbb5) 

Comment 3

[Olivier Cahagne]

related: bug 167233
does it still happen with latest nightly build ?

Comment 4

[greer]

Possibly. Talkback shows one crash in a build on the 24th.

Trunk (nsWindowWatcher::GetActiveWindow):      
 Total         237
 Unique Users  148
   1 2002092404
  20 2002092308
   7 2002092304
...and on.

Could be that both of these crashes are connectivity problems and this is a dupe
of 167233. The checkin for bug 167233 (@ nsWindowWatcher::GetActiveWindow) went
in on the 23rd and the crashes drop off sharply. We will have to look at
Talkback data in the next few days to see if that crash in the 9/24 build is an
anomaly or not. 

Comment 5

[Olivier Cahagne]

do you still crash using latest 1.2 build ?
http://ftp.mozilla.org/pub/mozilla/nightly/latest-1.2

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

-> embedding: APIs, as a guess based on the path to the file

Comment 7

[Roscoe Primrose]

Seeing the same thing here with 2002112304 on winXP

TB14415230K
TB14408066E

Comment 8

[Michael Lefevre]

can this still be reproduced with a recent build?

Comment 9

[Olivier Cahagne]

http://ftp26moz.newaol.com/pub/data/crash-data/rankoutput.html shows this stack 
signature once or twice a day.

Comment 10

[Michael Lefevre]

well I can't see any other open bugs with this signature (previously there's bug
81629, bug 160590 and bug 167233), so confirming this.

reassigning based on previous bug (and the fact that embedding: APIs doesn't
sound right to me...)

Comment 11

[timeless]

embedding apis is kind of right. it's only wrong because in almost all cases the
problem is a caller, but the caller is a javascript object or some dom critter,
and we can't track that down without a debugger because that information doesn't
appear in stack traces. it's not a toolkit/widgets bug.

Comment 12

[Ron Thigpen]

I've been seeing a spate of similar new window crashes on the recent line of
1.3b nightlies.

Currently using:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030113

Some Talkback IDs:
TB16205410E
TB16167910Q
TB16136413Y
TB16135398H
TB16033788X

Comment 13

[Olivier Cahagne]

Roscoe, Ron, does it happen with a fresh profile "mozilla -profilemanager" ?

This is supposed to be fixed in bug 167233 but still showing in the topcrashers'
list.
Adding 'topcrash' keyword although it only shows as #63 on the Trunk
topcrashers' list.

Adding 'stackwanted' to make sure this is indeed the same stack: TB16136413Y.

Comment 14

[Ron Thigpen]

This has been occuring on a profile that has existed since 1.2.  Not that it
isn't a decent way to try and isolate causation, but aren't profiles supposed to
migrate forward cleanly at this time? 

FWIW, I haven't noticed this issue on the 20030116 and 20030115 builds, but it
could just be the sites I've visited.

Comment 15

[Doron Rosenberg (IBM)]

useless stack:

ntdll.dll + 0x29181 (0x77f89181)
ntdll.dll + 0xcf28 (0x77f6cf28)
ntdll.dll + 0x7586 (0x77f67586)
USER32.dll + 0x124c (0x77e7124c) 

Comment 16

[Olivier Cahagne]

please reopen if you still crash with latest nightly build.

*** This bug has been marked as a duplicate of 167233 ***

Comment 17

[Mrten]

as i do not see this crash anymore, i won't reopen it. 

i think however that you are a bit 'duplicate-happy', as i never use mozilla's
IMAP, and i don't even have mailnews installed.

Comment 18

[Olivier Cahagne]

http://ftp.mozilla.org/pub/data/crash-data/detailed-crash-analysis-all.html
shows 298 crashes with the same signature. Very few comments mention IMAP, most
of them were about surfing, opening a new window, etc. That's the reason I
believe it's dupe of bug 167233 which is the only bug report with this stack
(eventhough it seems to be linked with IMAP), got fixed in September and there's
no more similar stack after September. comment 14 mentions it doesn't crash anymore.
I may be wrong but this seems to fixed on the trunk.

Comment 19

[Greg K.]

I think I may have encountered this crash using
FizzillaMach/2003-05-01-08-trunk, generating TB256784E.

Comment 20

[Greg K.]

Attachment: Crash report generated by FizzillaMach/2003-05-01-08-trunk showing crash at nsWindowWatcher::GetActiveWindow after clicking "our opportunities" on <http://prod.kaiserpermanentejobs.org/home.cfm?0=0>

Comment 21

[Mike Kaply [:mkaply]]

bryner,

Should another if (mActive) have been added here:

http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsFocusController.cpp#152

Comment 22

[rnorberg]

We have seen this on OS/2 : it traps sys3175 embedcmp.dll
Symptom : trap
Phase Found : FVT function verification test
Testcase :
htttp://jce.iaik.tugraz.at/servlet/demo.sslclientinfo.SSLClientInfoServlet
Build ID : mozilla 20030430 en_US os/2
Platform : IBM PC 6579-a4u 78-VPWMV OS : MCP2

Description : mozilla traps when opening new window

    Link takes you to a page that checks SSLClientInfo.
    Select the link opens a page that automatically opens a new page.
    The trap happens just before a warning popup - "website certified by an
Unknown Authority".    

Does Mozilla fail on Windows in the same way? I could not recreate on windows 2k
Did this Mozilla function work on a previous build (Regression)? no
Reproducibility : intermittent
uninstall/install
Steps to Recreate : 
    1. Uninstall Browser - an older browser build with a profile
    2. Install Browser - create new profile
    3. Open
http://jce.iaik.tugraz.at/servlet/demo.sslclientinfo.SSLClientInfoServlet

       You are redirected here by our testcase :
           http://ei4b.test.austin.ibm.com/BrwTestSSL/BrwTestSSL.html
           Link on line "SSL Client Info Test  presents you with a new
certificate, and asks for your personal certificate."

    4. After warning and certificate popups you should be taken to a webpage -
SSLClientInfo
Actual Results : trap sys3175 after selecting link - checking website certification
Expected Results : warning popup, then taken to page
Workaround - restart browser - works afterwards without failure.

Comment 23

[Dan M]

Attachment: active window must be a top-level docshell

I see many reports of this crash in Talkback. I believe it's happening to
/somebody/. Just not me or anyone here. So here's the latest thinking on this
problem.

The "only way" this short and relatively benign method could crash is if
mActiveWindow referred to some deleted window. By the time the crash happens
the damage has already been done, so the crash stack trace is useless. (A quick
fix would be, as bryner once suggested in related bug 167233, to use a weakref
rather than a simple non-owning ref. But that just masks the real underlying
problem, that somehow someone isn't keeping the active window reference
up-to-date.)

Without a testcase that works for us, we're reduced to eyeballing. Much
eyeballing. WindowWatcher could have its active window pointer left dangling
after the active window was destroyed if somehow by mistake the DOM Window WW
uses to represent the active top-level window didn't correspond to the
destroyed window's top-level DocShell. nsFocusController calculates that
top-level DOM window from its given focus DOM window by traversing a chain of
parent pointers. And it does this at a somewhat indeterminate time; after the
OS activates and focuses a new window. bryner and I wonder if occasionally a
stroke of timing causes us to try to set WW's active top-level window before
the chain of container DocShells has been completely hooked up.

This patch admits as active windows only DOM windows that are already known to
represent some top-level window's top-level DocShell. It's a good check to make
anyway. If we've stumbled into the correct explanation for this bug, this
should fix the crash. The side effect will be that sometimes the active window
pointer is incorrect; it will refer to some valid but inactive window (or
null). This is not a major concern, but it could screw up parenting of
otherwise orphaned modal dialogs and alerts. If this crash subsequently goes
away, the next step will be to notice the returned error in nsFocusController
and schedule a repeat attempt to set the active window after the DocShell chain
has been established.

If this doesn't fix the crash, I'm nearly ready to give up and take the weak
pointer solution.

Comment 24

[Brian Ryner (not reading)]

Comment on attachment 126965 [details] [diff] [review]
active window must be a top-level docshell

Sure, sounds fine.  We should be able to tell relatively soon from talkback
data if this is the culprit.

Only one nit, instead of NS_ASSERTION(0, ...) you can just use NS_ERROR() for
the same effect.

Comment 25

[Dan M]

patch is in. fingers crossed.

Comment 26

[Dan M]

Talkback reports no incidents involving nsWindowWatcher::GetActiveWindow since
this patch was checked in a week ago. Would those who can see this crash be
certain to take this patch out for a tour? It's not in Mozilla 1.4; you'll need
to spin your own or run with a nightly build from July 4th or later.

Comment 27

[Mike Kaply [:mkaply]]

I'd like this in 1.4.1.

Comment 28

[Mike Kaply [:mkaply]]

Comment on attachment 126965 [details] [diff] [review]
active window must be a top-level docshell

If anyone involved in this bug thinks it shouldn't go in 1.4.1, speak now or
forever hold your peace.

Comment 29

[Dan M]

Patch was checked in to the 1.4 branch three days ago.

Still no mention of this crash in Talkback from a build later than June. There's
hope for optimism. Gonna call this fixed in another week like this last one.
(And then worry about rescheduling the setting of the active window, which is
apparently sometimes incorrect; see comment 23.)

Comment 30

[Dan M]

It's been a month and more, and I'm told that as of today talkback reports no
crashes with this signature from a build dated after the patch was checked in.
Nifty. Guess we stumbled into the right solution, then. I'm calling it fixed,
and consequently opening bug 217277 for the implied focus issue.