###!!! ASSERTION: Why are we creating new state when disabled?: '!gTimelineDisabled', file i:/build/mozilla/xpcom/ds/nsTimelineService.cpp, line 222 Break: at file i:/build/mozilla/xpcom/ds/nsTimelineService.cpp, line 222 nsDebug::WarnIfFalse(const char * 0x002dc834, const char * 0x002dc820, const char * 0x002dc7f0, int 222) line 387 + 21 bytes GetThisThreadData() line 222 + 34 bytes NS_TimelineMarkV(const char * 0x00419fd0, char * 0x0012fd7c) line 350 + 5 bytes NS_TimelineForceMark(const char * 0x00419fd0) line 364 + 13 bytes main1(int 1, char * * 0x004443d0, nsISupports * 0x00fd4490) line 1281 + 11 bytes Callee: mhammond 3.10 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/ds/nsTimelineService.cpp&rev=3.10&mark=221-222#206 Caller: dp 1.325 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/bootstrap/nsAppRunner.cpp&rev=1.398&mark=1280#1277 If the assert should be removed, please remove it.

The assertion is good (it just caught a problem for me.) The caller seems bad. A comment explicitly says that it wants a printout when the timeline is runtime-disabled, but in that case NS_TimelineForceMark() will always trigger the assertion failure. Not only that, but it'll have a bogus timestamp, because that's all the tls state is being used for: the initTime. And finally, I don't see the initial entry to "main1". Unless users were emitting that manually before firing anything up? That would make sense, but I can find no evidence of it anywhere. So perhaps the right thing to do is to just eliminate the "...main1" printout. I hesitate to do that, though, because the (admittedly ancient) tools in tools/performance/startup require it. Here's a patch that assumes we want to keep it. It adds an initTime parameter to NS_TimelineForceMark and uses that if the timeline is disabled. Really, that ought to be initialized from an environment variable or something, but if you actually care, then you have the timeline enabled anyway.

Sounds like a better solution would be to nuke --enable-timeline completely.

nsITimelineService was removed by bug 579571, so this is no longer relevant.