563643 - [Debug MacOSX SeaMonkey] leak test: "ASSERTION: Want to fire mutation events, but it's not safe" since bug 429175 landing. ("all" other test suites too)

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Serge Gautherie (:sgautherie)]

Examples:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1272966480.1272967513.17287.gz&fulltext=1
Linux comm-central-trunk leak test build on 2010/05/04 02:48:00
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1272980836.1272982347.16548.gz&fulltext=1
OS X 10.5 comm-central-trunk leak test build on 2010/05/04 06:47:16

I'm not copying the stack as afaik it's unreliable on these platforms ftb.
(And our Windows build has another issue atm :-()

Regression timeframe:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1acce93e0198&tochange=02ca6f9215bc
"You are not authorized to access bug #429175."

Comment 1

[Jesse Ruderman]

Probably the same as bug 563491.

Why is this sev:blocker?  Is this happening for *every* Bd on Seamonkey?

Comment 2

[Serge Gautherie (:sgautherie)]

(In reply to comment #1)

> Probably the same as bug 563491.

I can't tell: "You are not authorized to access bug #563491" either.

> Why is this sev:blocker?  Is this happening for *every* Bd on Seamonkey?

Because an assertion (and "alive test failed") regression seems bad enough. *Yes*!

Comment 3

[Serge Gautherie (:sgautherie)]

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1273319980.1273326212.14846.gz&fulltext=1
WINNT 5.2 comm-central-trunk leak test build on 2010/05/08 04:59:40
{
###!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnonymousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file e:/builds/slave/comm-central-trunk-win32-debug/build/mozilla/content/base/src/nsContentUtils.cpp, line 3392
gklayout!nsGenericElement::SetAttr+0x00000000000000A2 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\content\base\src\nsgenericelement.cpp, line 4585)
gklayout!nsGenericElement::SetAttribute+0x000000000000014E (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\content\base\src\nsgenericelement.cpp, line 2370)
gklayout!nsXULElement::SetAttribute+0x0000000000000014 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\content\xul\content\src\nsxulelement.h, line 553)
gklayout!nsIDOMElement_SetAttribute+0x0000000000000162 (e:\builds\slave\comm-central-trunk-win32-debug\build\objdir\mozilla\js\src\xpconnect\src\dom_quickstubs.cpp, line 4396)
mozjs!js_Interpret+0x000000000000D83B (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsops.cpp, line 2199)
mozjs!js_Invoke+0x00000000000008A7 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsinterp.cpp, line 831)
mozjs!js_InternalInvoke+0x0000000000000082 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsinterp.cpp, line 882)
mozjs!js_InternalGetOrSet+0x000000000000004E (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsinterp.cpp, line 919)
mozjs!JSScopeProperty::set+0x0000000000000078 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsscope.h, line 1006)
mozjs!js_SetPropertyHelper+0x000000000000066B (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsobj.cpp, line 4991)
mozjs!js_Interpret+0x000000000000C01C (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsops.cpp, line 1821)
mozjs!js_Invoke+0x00000000000008A7 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\jsinterp.cpp, line 831)
gklayout!nsXPCWrappedJSClass::CallMethod+0x0000000000001093 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1696)
gklayout!nsXPCWrappedJS::CallMethod+0x0000000000000041 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 571)
xpcom_core!PrepareAndDispatch+0x0000000000000316 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp, line 114)
xpcom_core!SharedStub+0x0000000000000016 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp, line 142)
nsappshell!nsContentTreeOwner::SetStatusWithContext+0x00000000000000D9 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\xpfe\appshell\src\nscontenttreeowner.cpp, line 457)
nsappshell!nsContentTreeOwner::SetStatus+0x000000000000004F (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\xpfe\appshell\src\nscontenttreeowner.cpp, line 483)
gklayout!nsGlobalWindow::SetStatus+0x0000000000000100 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\dom\base\nsglobalwindow.cpp, line 3152)
gklayout!nsGlobalWindow::SetNewDocument+0x000000000000036B (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\dom\base\nsglobalwindow.cpp, line 1703)
gklayout!DocumentViewerImpl::InitInternal+0x0000000000000680 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\layout\base\nsdocumentviewer.cpp, line 951)
gklayout!DocumentViewerImpl::Init+0x000000000000001B (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\layout\base\nsdocumentviewer.cpp, line 691)
docshell!nsDocShell::SetupNewViewer+0x0000000000000EBA (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\docshell\base\nsdocshell.cpp, line 7360)
docshell!nsDocShell::Embed+0x0000000000000039 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\docshell\base\nsdocshell.cpp, line 5496)
docshell!nsDocShell::CreateContentViewer+0x00000000000006D6 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\docshell\base\nsdocshell.cpp, line 7142)
docshell!nsDSURIContentListener::DoContent+0x0000000000000139 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\docshell\base\nsdsuricontentlistener.cpp, line 138)
docshell!nsDocumentOpenInfo::TryContentListener+0x00000000000002F0 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\uriloader\base\nsuriloader.cpp, line 732)
docshell!nsDocumentOpenInfo::DispatchContent+0x00000000000005A9 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\uriloader\base\nsuriloader.cpp, line 434)
docshell!nsDocumentOpenInfo::OnStartRequest+0x00000000000001C3 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\uriloader\base\nsuriloader.cpp, line 280)
necko!nsBaseChannel::OnStartRequest+0x000000000000010F (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\netwerk\base\src\nsbasechannel.cpp, line 665)
necko!nsInputStreamPump::OnStateStart+0x00000000000000A4 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\netwerk\base\src\nsinputstreampump.cpp, line 441)
necko!nsInputStreamPump::OnInputStreamReady+0x0000000000000070 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\netwerk\base\src\nsinputstreampump.cpp, line 397)
xpcom_core!nsInputStreamReadyEvent::Run+0x000000000000004A (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\xpcom\io\nsstreamutils.cpp, line 113)
xpcom_core!nsThread::ProcessNextEvent+0x00000000000001FA (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\xpcom\threads\nsthread.cpp, line 527)
xpcom_core!NS_ProcessNextEvent_P+0x0000000000000053 (e:\builds\slave\comm-central-trunk-win32-debug\build\objdir\mozilla\xpcom\build\nsthreadutils.cpp, line 250)
gkwidget!nsBaseAppShell::Run+0x000000000000005D (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\widget\src\xpwidgets\nsbaseappshell.cpp, line 178)
gkwidget!nsAppShell::Run+0x0000000000000042 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\widget\src\windows\nsappshell.cpp, line 239)
toolkitcomps!nsAppStartup::Run+0x000000000000006B (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\toolkit\components\startup\src\nsappstartup.cpp, line 184)
xul!XRE_main+0x0000000000002D58 (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\toolkit\xre\nsapprunner.cpp, line 3564)
seamonkey!NS_internal_main+0x000000000000010F (e:\builds\slave\comm-central-trunk-win32-debug\build\suite\app\nssuiteapp.cpp, line 103)
seamonkey!wmain+0x000000000000011E (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\toolkit\xre\nswindowswmain.cpp, line 120)
seamonkey!__tmainCRTStartup+0x00000000000001A6 (f:\sp\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 594)
seamonkey!wmainCRTStartup+0x000000000000000D (f:\sp\vctools\crt_bld\self_x86\crt\src\crtexe.c, line 414)
kernel32!ProcessIdToSessionId+0x0000000000000209
}

Fwiw, before the assertion, there are multiple WARNINGs, some I'm used to, some I'm not (yet) like:
{
WARNING: NS_ENSURE_TRUE(browserChrome) failed: file e:/builds/slave/comm-central-trunk-win32-debug/build/mozilla/docshell/base/nsDocShell.cpp, line 10333
WARNING: Something wrong when creating the docshell for a frameloader!: file e:/builds/slave/comm-central-trunk-win32-debug/build/mozilla/content/base/src/nsFrameLoader.cpp, line 1043
}

Comment 4

[Robert Kaiser]

(In reply to comment #1)
> Is this happening for *every* Bd on Seamonkey?

From all I can tell, yes. Every single one.

Comment 6

[Serge Gautherie (:sgautherie)]

V.Duplicate

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Seems like the fix in bug 563491 didn't fix this.

It would be great to get a properly formatted stack to see what the issue is here.

Comment 8

[Robert Kaiser]

(In reply to comment #7)
> It would be great to get a properly formatted stack to see what the issue is
> here.

How does attachment 454629 [details] work for you?

Comment 10

[Serge Gautherie (:sgautherie)]

(Morphed?) Bug still there, but on "OS X debug" only:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1283946897.1283947974.8306.gz&fulltext=1
OS X 10.5 comm-central-trunk leak test build on 2010/09/08 04:54:57
{
...
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: file:///builds/slave/comm-central-trunk-macosx-debug/build/objdir/mozilla/dist/SeaMonkeyDebug.app/Contents/MacOS/components/messageWakeupService.js :: anonymous :: line 56"  data: no]
************************************************************
...
###!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnonymousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file /builds/slave/comm-central-trunk-macosx-debug/build/mozilla/content/base/src/nsContentUtils.cpp, line 3657
nsCRT::IsAsciiSpace(unsigned short)+0x0000D704 [/builds/slave/comm-central-trunk-macosx-debug/build/objdir/mozilla/dist/SeaMonkeyDebug.app/Contents/MacOS/components/libgklayout.dylib +0x003534F8]
nsSmallVoidArray::operator[](int) const+0x0002BDBA [/builds/slave/comm-central-trunk-macosx-debug/build/objdir/mozilla/dist/SeaMonkeyDebug.app/Contents/MacOS/components/libgklayout.dylib +0x003DE914]
...
}

Comment 11

[Robert Kaiser]

I wonder that we are using messageWakeupService.js at all, but that's a packaging issue, and maybe it just masks the other one. We should package the message wakeup service in any case, but I thought it's unused without e10s.

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to comment #10)
> * Call to xpconnect wrapped JSObject produced this error:  *
> [Exception... "Component returned failure code: 0x80570016
> (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult:
> "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame ::
> file:///builds/slave/comm-central-trunk-macosx-debug/build/objdir/mozilla/dist/SeaMonkeyDebug.app/Contents/MacOS/components/messageWakeupService.js
> :: anonymous :: line 56"  data: no]

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1283959903.1283967713.6304.gz&fulltext=1
WINNT 5.2 comm-central-trunk build on 2010/09/08 08:31:43
doesn't report it and pass :-|

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1283960452.1283968964.11816.gz&fulltext=1
WINNT 5.2 comm-central-trunk leak test build on 2010/09/08 08:40:52
reports it too and pass, so it seems unrelated to the assertion :-)

(In reply to comment #11)
> We should package the message wakeup service in any case

You filed bug 563643.

Comment 13

[Serge Gautherie (:sgautherie)]

(In reply to comment #12)
> You filed bug 563643.

Bug 594430!

Comment 14

[Serge Gautherie (:sgautherie)]

(In reply to comment #12)
> http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1283960452.1283968964.11816.gz&fulltext=1
> WINNT 5.2 comm-central-trunk leak test build on 2010/09/08 08:40:52
> reports it too and pass, so it seems unrelated to the assertion :-)

I filed bug 594487.

Comment 15

[Serge Gautherie (:sgautherie)]

Jonas, what about comment 8?

Comment 16

[Bruno 'Aqualon' Escherl]

Still an issue on our OS X 10.5 comm-central-trunk debug test mochitests-2/5 tinderbox. Those assertion occurs even before the first test is executed. I also compared those logs to Rev3 MacOSX Leopard 10.5.8 mozilla-central debug test mochitests-2/5 but except the warnings from nsMsgContentPolicy.cpp I don't see any major differences between those logs. So it's not really obvious for me, why we hit that assertion and Firefox doesn't.

Comment 17

[Serge Gautherie (:sgautherie)]

(In reply to comment #16)

> OS X 10.5 comm-central-trunk debug test mochitests-2/5

Right, I had noticed it too.
Note that it just happens for "all" test suites.

Maybe the stack is "better" on the latters, like:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1285026728.1285027909.22734.gz&fulltext=1
OS X 10.5 comm-central-trunk debug test mochitests-2/5 on 2010/09/20 16:52:08
{
###!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnonymousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file /builds/slave/comm-central-trunk-macosx-debug/build/mozilla/content/base/src/nsContentUtils.cpp, line 3666
nsContentUtils::HasMutationListeners [content/base/src/nsContentUtils.cpp:3669]
nsGenericElement::SetAttr [content/base/src/nsGenericElement.cpp:4612]
nsGenericElement::SetAttr [content/base/src/nsGenericElement.h:388]
nsGenericElement::SetAttribute [content/base/src/nsGenericElement.cpp:2398]
nsXULElement::SetAttribute [content/xul/content/src/nsXULElement.h:561]
nsContentTreeOwner::XULWindow [xpfe/appshell/src/nsContentTreeOwner.cpp:955]
nsXULWindow::EnsurePrimaryContentTreeOwner [xpfe/appshell/src/nsXULWindow.cpp:966]
...
}

In any case, it could help to know which part(s) of the assertion is false.

> it's not really obvious for me, why we hit that assertion and Firefox doesn't.

Fwiw, I won't trust MacOSX SeaMonkey boxes until they've been clobbered (eventually):
for example, "leak test" still reports the 2 (fixed) messageWakeupService.js bugs ... which makes me suspicious :-|

Comment 18

[Serge Gautherie (:sgautherie)]

Clobbered by bug 598546, not reporting messageWakeupService.js exception anymore,
but bug still there:

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1285167528.1285172240.10334.gz&fulltext=1
OS X 10.5 comm-central-trunk leak test build on 2010/09/22 07:58:48
{
###!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnonymousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file /builds/slave/comm-central-trunk-macosx-debug/build/mozilla/content/base/src/nsContentUtils.cpp, line 3666
mozilla::layers::ImageContainer::Manager()+0x00185EC0 [/builds/slave/comm-central-trunk-macosx-debug/build/objdir/mozilla/dist/bin/XUL +0x005B1F32]
...
}

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1285182960.1285183902.28470.gz&fulltext=1
OS X 10.5 comm-central-trunk debug test mochitests-2/5 on 2010/09/22 12:16:00
{
##!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnonymousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file /builds/slave/comm-central-trunk-macosx-debug/build/mozilla/content/base/src/nsContentUtils.cpp, line 3666
nsContentUtils::HasMutationListeners [content/base/src/nsContentUtils.cpp:3669]
nsGenericElement::SetAttr [content/base/src/nsGenericElement.cpp:4612]
...
###!!! ASSERTION: Want to fire mutation events, but it's not safe: '(aNode->IsNodeOfType(nsINode::eCONTENT) && static_cast<nsIContent*>(aNode)-> IsInNativeAnonymousSubtree()) || sScriptBlockerCount == sRemovableScriptBlockerCount', file /builds/slave/comm-central-trunk-macosx-debug/build/mozilla/content/base/src/nsContentUtils.cpp, line 3666
nsContentUtils::HasMutationListeners [content/base/src/nsContentUtils.cpp:3669]
nsXULElement::UnsetAttr [content/xul/content/src/nsXULElement.cpp:1368]
...
}

Most test suites report
{
WARNING: NS_ENSURE_TRUE(browserChrome) failed: file /builds/slave/comm-central-trunk-macosx-debug/build/mozilla/docshell/base/nsDocShell.cpp, line 10724
WARNING: Something wrong when creating the docshell for a frameloader!: file /builds/slave/comm-central-trunk-macosx-debug/build/mozilla/content/base/src/nsFrameLoader.cpp, line 1316
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file /builds/slave/comm-central-trunk-macosx-debug/build/mozilla/content/base/src/nsFrameLoader.cpp, line 262
}
just before the first occurrence of the assertion.

Tentative guess: something is wrong with some (XUL) piece of a MacOSX specific UI? w.r.t. its "hidden" window??

Comment 19

[Serge Gautherie (:sgautherie)]

"blocking2.0=?":
this has been failing for 6,5 months :-(

Comment 20

[Johnny Stenback (:jst)]

Olli, can you have a look at this regression? I'm not convinced it's a blocker, but I'd like to at least understand this a bit better before making that decision.

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

Does Seamonkey use mutation event listener in its chrome?

Comment 22

[Robert Kaiser]

http://mxr.mozilla.org/comm-central/search?string=DOMAttrModified&regexp=1&find=%2Fsuite%2F cases should, I think, never be called in the main window, as we don't open mailnews or the bookmarks properties dialog.

Current stacks should be in:
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1291376156.1291379678.14926.gz&fulltext=1 (OS X 10.5 comm-central-trunk leak test build)
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1291381397.1291382549.31488.gz&fulltext=1 (OS X 10.6 comm-central-trunk leak test build)

Interestingly, we hit this in this alive test on Mac but not on other platforms.

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

I don't have a mac with me right now so if this happens nowadays only
on mac, need to wait a week before I can look at this again.

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

But anyway, this is a case when C++ calls some JS implemented xpcom object
which then modifies DOM at wrong time.
So either the fix should be that C++ should call the possibly-implemented-in-JS 
method when it is "safe", or the JS object should modify DOM when
it is "safe". First one would be a gecko bug, latter one Seamonkey bug. 

So, I'm not 100% sure this should block 2.0.

Comment 25

[Johnny Stenback (:jst)]

Not blocking then, but would love to take a safe fix.

Comment 26

[Robert Kaiser]

From IRC:

<smaug> KaiRo: well, something in Seamonkey's nsIXULBrowserWindow implementation changes DOM at "unsafe" time

I guess that could be a good data point for someone trying to look into this. Neil, I know you have no Mac and it's only happening there, but perhaps you have some insight on what could be happening there.

Comment 27

[Serge Gautherie (:sgautherie)]

(In reply to comment #26)
> <smaug> KaiRo: well, something in Seamonkey's nsIXULBrowserWindow
> implementation changes DOM at "unsafe" time

The interface:
http://mxr.mozilla.org/comm-central/source/mozilla/xpfe/appshell/public/nsIXULBrowserWindow.idl#53
Firefox code:
http://mxr.mozilla.org/mozilla-central/search?string=nsIXULBrowserWindow&case=1&find=%2Fbrowser%2F
SeaMonkey code:
http://mxr.mozilla.org/comm-central/search?string=nsIXULBrowserWindow&case=on&find=%2Fsuite%2F

At first glance, (/suite/browser/ part),
*unless it's related to updateStatusField (removal) which would be bug 608955,
*the difference should be in either setOverLink or onBeforeLinkTraversal...

Comment 28

[[e-mail]]

> gklayout!nsGlobalWindow::SetStatus+0x0000000000000100
> (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\dom\base\nsglobalwindow.cpp,
> line 3152)
> gklayout!nsGlobalWindow::SetNewDocument+0x000000000000036B
> (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\dom\base\nsglobalwindow.cpp,
> line 1703)
> gklayout!DocumentViewerImpl::InitInternal+0x0000000000000680
> (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\layout\base\nsdocumentviewer.cpp,
> line 951)
This isn't supposed to happen. It's not safe for SetNewDocument to call SetStatus! In my debug build, it adds a script runner which executes as DocumentViewerInternal::InitInternal returns.

Comment 29

[Serge Gautherie (:sgautherie)]

(In reply to comment #28)
> > gklayout!nsGlobalWindow::SetStatus+0x0000000000000100
> > (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\dom\base\nsglobalwindow.cpp,
> > line 3152)
> > gklayout!nsGlobalWindow::SetNewDocument+0x000000000000036B
> > (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\dom\base\nsglobalwindow.cpp,
> > line 1703)
> > gklayout!DocumentViewerImpl::InitInternal+0x0000000000000680
> > (e:\builds\slave\comm-central-trunk-win32-debug\build\mozilla\layout\base\nsdocumentviewer.cpp,
> > line 951)
> This isn't supposed to happen. It's not safe for SetNewDocument to call
> SetStatus! In my debug build, it adds a script runner which executes as
> DocumentViewerInternal::InitInternal returns.

Sorry Neil, that stack was from
(In reply to comment #3)
> http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1273319980.1273326212.14846.gz&fulltext=1
> WINNT 5.2 comm-central-trunk leak test build on 2010/05/08 04:59:40
but that case is not happening anymore: only MacOSX still fails.

Afaict, current 'leak test build' stacks from
*10.5 are useless, for some reason :-<
*10.6 looks +/- the same as the old 10.5 stacks copied here.

Comment 30

[[e-mail]]

OK, so this is the interesting part of the stack:
>nsXULElement::SetAttribute [content/xul/content/src/nsXULElement.h:561]
>nsContentTreeOwner::XULWindow [xpfe/appshell/src/nsContentTreeOwner.cpp:979]
>nsXULWindow::EnsurePrimaryContentTreeOwner [xpfe/appshell/src/nsXULWindow.cpp:966]
>nsXULWindow::ContentShellAdded [xpfe/appshell/src/nsXULWindow.cpp:1610]
>nsChromeTreeOwner::ContentShellAdded [xpfe/appshell/src/nsChromeTreeOwner.cpp:271]
When we create the primary content shell (by construction of the <tabbrowser>'s anonymous <browser> element) the XUL window creates a content tree owner which then, this being a Mac, fiddles with the title modifiers.

Comment 31

[[e-mail]]

Oh, and the reason Firefox doesn't see this is that they've given up on contenttitlesetting and #ifdef the title modifiers instead.

Comment 32

[[e-mail]]

Attachment: Proposed patch

Comment 33

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 498422 [details] [diff] [review]
Proposed patch

r+ assuming the current tests pass with this.

Comment 34

[Stefan [:stefanh]]

I ran leaktest.py with my seamonkey trunk debug build with the patch applied, and the assertions where gone.

Comment 35

[Serge Gautherie (:sgautherie)]

(In reply to comment #34)

Very good news :-)
I think they want a Firefox Try run now, before check-in.

Comment 36

[[e-mail]]

Attachment: With extra ifdefs as agreed on IRC

Comment 37

[[e-mail]]

(In reply to comment #35)
> I think they want a Firefox Try run now, before check-in.
Are you volunteering?

Comment 38

[Serge Gautherie (:sgautherie)]

(In reply to comment #37)
> Are you volunteering?

Why not.

[e-mail] – Sat Dec 18 16:43:39 2010 PST
http://hg.mozilla.org/try/rev/7118b3bb3cce
with a 3rd |#if defined(XP_MACOSX)|.

Comment 39

[Serge Gautherie (:sgautherie)]

Attachment: (Av1b) With 2 extra ifdefs as agreed on IRC [Checked in: Comment 41]

Per comment 38.  Passed on Try.

"approval2.0=?":
MacOSX SeaMonkey bustage fix.

Comment 40

[Serge Gautherie (:sgautherie)]

Ping for approval...

Comment 41

[Serge Gautherie (:sgautherie)]

Comment on attachment 498564 [details] [diff] [review]
(Av1b) With 2 extra ifdefs as agreed on IRC
[Checked in: Comment 41]

http://hg.mozilla.org/mozilla-central/rev/d04d53230330

Comment 42

[Serge Gautherie (:sgautherie)]

Firefox is still green and SeaMonkey is fixed per

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1295979675.1295982024.10991.gz
OS X 10.6 comm-central-trunk leak test build on 2011/01/25 10:21:15
{
check: 5279/0
}

V.Fixed

Comment 43

[Serge Gautherie (:sgautherie)]

(In reply to comment #31)
> Oh, and the reason Firefox doesn't see this is that they've given up on
> contenttitlesetting and #ifdef the title modifiers instead.

Please file a Firefox follow-up as need be.

Comment 44

[Philip Chee]

>> Oh, and the reason Firefox doesn't see this is that they've given up on
>> contenttitlesetting and #ifdef the title modifiers instead.

> Please file a Firefox follow-up as need be.
I think they are pretty set in their preference to pre-process/IFDEF everything.