Closed Bug 693821 Opened 10 years ago Closed 10 years ago

Using TimeDuration/TimeStamp from static constructors should assert

Categories

(Core :: XPCOM, defect, P3)

x86
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla10

People

(Reporter: bzbarsky, Assigned: dbaron)

References

Details

Attachments

(1 file)

The classes are possibly not initialized properly at that point.
Do we want each implementation to assert what it requires, or do we want the same assertions across platforms?  The first (for the Mac one) is pretty straightforward.
untested
Attachment #566362 - Flags: review?(bzbarsky)
Comment on attachment 566362 [details] [diff] [review]
add assertions to mac code

r=me
Attachment #566362 - Flags: review?(bzbarsky) → review+
Prior to the patch in bug 693219 this patch yields, on a mac debug tinderbox builder:

###!!! ABORT: calling TimeDuration too early: 'gInitialized', file /builds/slave/try-osx64-dbg/build/xpcom/ds/TimeStamp_darwin.cpp, line 133
WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/slave/try-osx64-dbg/build/xpcom/base/nsTraceRefcntImpl.cpp, line 172
WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/slave/try-osx64-dbg/build/xpcom/base/nsTraceRefcntImpl.cpp, line 172
WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/slave/try-osx64-dbg/build/xpcom/base/nsTraceRefcntImpl.cpp, line 172
WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/slave/try-osx64-dbg/build/xpcom/base/nsTraceRefcntImpl.cpp, line 172
WARNING: XPCOM objects created/destroyed from static ctor/dtor: file /builds/slave/try-osx64-dbg/build/xpcom/base/nsTraceRefcntImpl.cpp, line 172
mozilla::TimeDuration::FromMilliseconds(double)+0x00000040 [/builds/slave/try-osx64-dbg/build/obj-firefox/dist/bin/XUL +0x0001C550]
__static_initialization_and_destruction_0(int, int)+0x00000036 [/builds/slave/try-osx64-dbg/build/obj-firefox/dist/bin/XUL +0x00004C9E]
global constructors keyed to _ZN13nsPresContext19PrefChangedCallbackE
Depends on: 693219
https://hg.mozilla.org/integration/mozilla-inbound/rev/5435ee09cf7b

I think that fixes this bug for now, since it will at least prevent bad things from happening again.  If it ends up doing it at the stage of somebody-landing-their-patch too often, we should revisit and make the platforms consistent in how they assert.
Assignee: nobody → dbaron
Priority: -- → P3
Target Milestone: --- → mozilla10
https://hg.mozilla.org/mozilla-central/rev/5435ee09cf7b
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.