362318 - Invalid warnings on startup: XPCOM objects created/destroyed from static ctor/dtor: 'gActivityTLS != BAD_TLS_INDEX && NS_PTR_TO_INT32(PR_GetThreadPrivate(gActivityTLS)) == 0'

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Adam Guthrie]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20061129 Minefield/3.0a1

Even after the fix for bug 326837 landed, I'm still seeing tons of these warnings on startup. I'm going to attach a log of the backtraces for all them. It looks like they are all stemming from nsLocalFileUnix.cpp.

Comment 1

[Adam Guthrie]

Attachment: backtraces for all the warnings

Comment 2

[Benjamin Smedberg]

I think the original patch I put on bug 326837 should fix this (the one with joshmoz-). Please try it.

Comment 3

[Adam Guthrie]

As I mentioned to bsmedberg on IRC, the patch in attachment 245017 [details] [diff] [review] doesn't fix the warnings.

Comment 4

[:Gijs (he/him)]

Just reproduced this on my windows xp build, from a trunk pull yesterday late afternoon PST (about 10pm CET). This is a debug build, so I can try to do a trace too.

Comment 5

[Benjamin Smedberg]

There are many real bugs here:

***

xpcom_core.dll!NS_LogCtor_P
xpcom_core.dll!nsDeque::nsDeque
xpcom_core.dll!nsCycleCollector::nsCycleCollector
msvcr71d.dll!_initterm

This is a static cyclecollector instance which should be created during xpcom startup. http://lxr.mozilla.org/mozilla/source/xpcom/base/nsCycleCollector.cpp#539

***

xpcom_core.dll!nsLocalFile::AddRef
xpcom_core.dll!NS_NewLocalFile_P
xpcom_core.dll!NS_NewNativeLocalFile_P
xul.dll!XRE_GetBinaryPath
xul.dll!XRE_main

(and several other localfile manipulations)

I believe this should be fixed by attachment 245017 [details] [diff] [review]

***

xpcom_core.dll!nsTArray_base::nsTArray_base
gklayout.dll!nsTArray<CellData *>::nsTArray<CellData *>
gklayout.dll!nsTPtrArray<CellData>::nsTPtrArray<CellData>
gklayout.dll!$E1

Real bug: static instance in gklayout
http://lxr.mozilla.org/mozilla/source/layout/tables/nsCellMap.cpp#45

***

gkgfx.dll!nsRect::nsRect
gkgfxthebes.dll!$E1

Real bug: static instance in thebes

I can file the layout/thebes/cyclecollector bugs separately, if that would be helpful.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Please file the layout one separately and cc me?  It should be easy to do that in module init.

Comment 7

[Benjamin Smedberg]

I have landed attachment 245017 [details] [diff] [review], which should take care of the XRE_GetBinaryPath set. Boris fixed 369099 about CellData. What's left now is the cyclecollector (filed as bug 369336), and static nsRect in thebes (which is not filed that I know of).

Comment 8

[Josh Aas]

Attachment: more backtraces, mac os x 2/23/07

Comment 9

[Josh Aas]

This is getting so bad on mac that it fills up my log backbuffer and thus my logs are totally useless. It would be nice if somebody would take responsibility for this and fix it. I know stopping warnings isn't a high priority for anyone, but this is at an unacceptable level. We either need to fix the bugs or turn off the warning by default.

There doesn't seem to be a point behind the warning if it isn't causing anybody to fix their bugs and the warning itself is pretty much worse than the bugs now.

Comment 10

[Benjamin Smedberg]

Instead of complaining in this meta-bug, perhaps complain in the individual bugs that have been analyzed and assigned to the correct people? These are all real bugs that will screw up leak stats, or even crash (the xpconnect one, for example).

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Benjamin, all blocking and depending bugs are resolved as fixed. How should we proceed with the remaining issue Josh is describing? I can still see it on Mac OS. I don't know anything about the background so it would be nice if you could give an advice. Thanks.

Comment 13

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I don't seem to see this issue anymore. Might just be me or something else. Waiting for more confirmation..

Comment 14

[Jesse Ruderman]

Works fine for me now too.  Adam, are you still seeing these?

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 10/03 - 10/13)]

Josh, is your reported problem also working now?

Comment 16

[Josh Aas]

I don't see this problem any more.

Comment 17

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Per comments #13, #14 and #16, resolving WFM.