User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce: It looks like the JS shell on macOS is subject to a race in static initializer order. The shell creates a static TimeDuration, which relies on another static initializer in TimeStamp_darwin.cpp but in my case they are not called in the right order. Actual results: JS shell crashes immediately on startup. Assertion failure: gInitialized (calling TimeDuration too early), at /Users/ptomato/jhbuild/source/mozjs/mozglue/misc/TimeStamp_darwin.cpp:104 Expected results: JS shell starts.

On Darwin this would cause a race between two static initializers.

Comment on attachment 8925723 [details] [diff] [review] Don't use TimeDuration in static initializer Review of attachment 8925723 [details] [diff] [review]: ----------------------------------------------------------------- Terrence is no longer at Mozilla. This looks fine though.

Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/af56f51a55b1 Don't use TimeDuration in static initializer. r=jandem

Comment on attachment 8925723 [details] [diff] [review] Don't use TimeDuration in static initializer [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: For developers working with embedded SpiderMonkey this fix is useful, as otherwise the js shell will crash immediately on some platforms User impact if declined: None, the js shell is only used by developers Fix Landed on Version: 58 Risk to taking this patch (and alternatives if risky): Very low risk, the changes are only in the js shell which is a developer tool String or UUID changes made by this patch: None See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment on attachment 8925723 [details] [diff] [review] Don't use TimeDuration in static initializer Fix seems low risk and has stabilized in Nightly for several weeks, ESR52+