Closed Bug 700827 Opened 14 years ago Closed 3 years ago

startup crash cal::getTimezoneService because timezone service and/or the UTC timezone isn't loaded and is therefore null. race condition?

Categories

(Calendar :: General, defect)

Lightning 1.0
x86_64
All
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: wsmwk, Unassigned)

References

()

Details

(Keywords: crash, regression, Whiteboard: [startupcrash])

Crash Data

+++ This bug was initially created as a clone of Bug #675608 +++ crashes are still occurring for lightning v1 + TB8. It is too early yet to know to what extent bug 675608 has or has not reduced crashiness. Line numbers in the stack are exactly the same as crashes cited in bug 675608. All crashes checked indicate version 1 of lightning is installed startup crash [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()] bp-e48b6b35-2293-4127-99f0-3c6e12111108 0 mozalloc.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:77 1 xul.dll NS_DebugBreak_P xpcom/base/nsDebugImpl.cpp:345 2 calbasecomps.dll cal::getTimezoneService calendar/base/src/calUtils.h:94 3 calbasecomps.dll cal::UTC calendar/base/src/calUtils.h:141 4 calbasecomps.dll calDateTime::SetNativeTime calendar/base/src/calDateTime.cpp:196 5 calbasecomps.dll calDateTime::SetProperty calendar/base/src/calDateTime.cpp:737 6 xul.dll XPC_WN_Helper_SetProperty js/src/xpconnect/src/xpcwrappednativejsops.cpp:1005
after one day of crash stats, it's pretty clear that Bug #675608 had a positive effect. But there are still some crashes.
settled down to #64 crash for TB8/lightning 1.0
perhaps related - mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::UTC() bp-5ea2fd9c-dd0b-4c24-8ff1-f4ae72111223 startup crash v9 0 mozalloc.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:77 1 xul.dll NS_DebugBreak_P xpcom/base/nsDebugImpl.cpp:345 2 calbasecomps.dll cal::UTC calendar/base/src/calUtils.h:143 3 calbasecomps.dll calDateTime::SetNativeTime calendar/base/src/calDateTime.cpp:196 4 calbasecomps.dll calDateTime::SetProperty calendar/base/src/calDateTime.cpp:737 5 xul.dll XPC_WN_Helper_SetProperty js/src/xpconnect/src/xpcwrappednativejsops.cpp:1026 6 mozjs.dll js::Shape::set js/src/jsscopeinlines.h:312 7 mozjs.dll js_NativeSet js/src/jsobj.cpp:5802 8 mozjs.dll js_SetPropertyHelper js/src/jsobj.cpp:6303 not startup crash v9 bp-64ce7fc3-1da3-4206-8828-178e42111208
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()] → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()] [@ mozalloc_abort | NS_DebugBreak_P | cal::UTC]
Whiteboard: [startupcrash]
mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::UTC() looks to be the same crash bp-9a24ba8f-0beb-4810-a01f-247592120830
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()] [@ mozalloc_abort | NS_DebugBreak_P | cal::UTC] → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()] [@ mozalloc_abort | NS_DebugBreak_P | cal::UTC] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::UTC()]
Stefan, any thoughts on this topcrash?
Flags: needinfo?(ssitter)
Flags: needinfo?(ssitter)
It's #120 top crasher in TB 17.0.2 so not a top crasher.
Keywords: topcrash
fallen, your fix in bug 675608 was only partly successful. Any further thoughts? signature is now mozalloc_abort(char const* const) | NS_DebugBreak | cal::getTimezoneService(). Combined signature crash count puts rank in top #80 of THunderbird 24.1.0 crashes
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()] [@ mozalloc_abort | NS_DebugBreak_P | cal::UTC] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::UTC()] → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()] [@ mozalloc_abort | NS_DebugBreak_P | cal::UTC] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::UTC()] [@ mozalloc_abort(char const* const) | NS_DebugBrea…
Flags: needinfo?(philipp)
I think this is some race condition / startup ordering thing. The timezone service and/or the UTC timezone isn't loaded and is therefore null, so I force a crash at that point. I currently can't reproduce this and as my goal is to get rid of our C++ code, so I think we are going to have to live with this for now.
Flags: needinfo?(philipp)
zoomed to #25 crash in TB31.3.0 and we aren't yet unthrottled for updates. In Version 31.2.0 this isn't even in the top 100 crashes. I don't know why the increase https://crash-stats.mozilla.com/report/index/1f47c722-30ec-4baa-be7f-3f0b02141208 is one such crash
Crash Signature: NS_DebugBreak | cal::UTC() ] [@ mozalloc_abort(char const* const) | NS_DebugBreak | cal::getTimezoneService()] → NS_DebugBreak | cal::UTC() ] [@ mozalloc_abort(char const* const) | NS_DebugBreak | cal::getTimezoneService()] [@ mozalloc_abort | NS_DebugBreak_P | cal::getTimezoneService] [@ mozalloc_abort | NS_DebugBreak | cal::UTC ] [@ mozalloc_abort | NS_DebugB…
Depends on: icaljs
new signature variation - Abort | Could not load UTC timezone, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | cal::UTC
Crash Signature: NS_DebugBreak | cal::getTimezoneService] → NS_DebugBreak | cal::getTimezoneService] [@ Abort | Could not load UTC timezone, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | cal::UTC]
OS: Windows 7 → All
#1 ranked startup crash for Thunderbird [1] another new signature Abort | Could not load timezone service, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | cal::getTimezoneService [1] https://crash-stats.mozilla.com/search/?uptime=%3C5&product=Thunderbird&date=%3E%3D2016-12-01T14%3A53%3A37.000Z&date=%3C2017-01-01T14%3A53%3A37.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=version&_columns=platform&_columns=uptime&_columns=user_comments&_columns=email#facet-signature mv, do you still get these crashes?
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()] [@ mozalloc_abort | NS_DebugBreak_P | cal::UTC] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::UTC()] [@ mozalloc_abort(char const* const) | NS_DebugBrea… → [@ mozalloc_abort | NS_DebugBreak_P | cal::UTC] [@ mozalloc_abort | NS_DebugBreak_P | cal::getTimezoneService] [@ mozalloc_abort | NS_DebugBreak | cal::UTC ] [@ mozalloc_abort | NS_DebugBreak | cal::getTimezoneService] [@ Abort | Could not load UTC ti…
Flags: needinfo?(cmv97)
Summary: startup crash [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()] → startup crash cal::getTimezoneService because timezone service and/or the UTC timezone isn't loaded and is therefore null
Blocks: 1234763
https://support.mozilla.org/en-US/questions/1162051 Not sure what to make of this but crash rate for 52.1.1 (ranked ~#76) is slightly higher than 45.8.0 despite roughly equal number of users.
Summary: startup crash cal::getTimezoneService because timezone service and/or the UTC timezone isn't loaded and is therefore null → startup crash cal::getTimezoneService because timezone service and/or the UTC timezone isn't loaded and is therefore null. race condition?
In beta versions we now have signature cal::getTimezoneService going back at least as far as 58.0b2 bp-1f303dc7-5423-48c6-95aa-cd86b0180102. signature is #16 crash for 60.0b3 crash signatures containing UTC from past 4 months - https://crash-stats.mozilla.com/search/?signature=~UTC&product=Thunderbird&date=%3E%3D2017-10-23T10%3A51%3A16.000Z&date=%3C2018-04-23T10%3A51%3A16.000Z&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature 1 Abort | Could not load UTC timezone, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | cal::UTC Add term 3496 83.00 % 2 Abort | Could not load UTC timezone, brace yourself and prepare for crash | mozalloc_abort | Abort | NS_DebugBreak | calDateTime::SetNativeTime Add term 228 5.41 % 3 Abort | Could not load UTC timezone, brace yourself and prepare for crash | mozalloc.dll@0x141b Add term 222 5.27 % 4 cal::UTC Add term 79 1.88 % 5 Abort | Could not load UTC timezone, brace yourself and prepare for crash | mozalloc.dll@0x10ad Add term 30 0.71 % 6 Abort | Could not load UTC timezone, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | calDateTime::SetNativeTime Add term 22 0.52 % 7 js::DateObject::setUTCTime Add term 16 0.38 % 8 UTCToLocalStandardOffsetSeconds Add term 13 0.31 % 9 Abort | Could not load timezone service, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | cal::UTC Add term 12 0.28 % 10 Abort | Could not load UTC timezone, brace yourself and prepare for crash | libmozalloc.so@0xf5c Add term 8 0.19 %
Crash Signature: timezone, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | cal::UTC] [@ Abort | Could not load timezone service, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | cal::getTimezoneService] → timezone, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | cal::UTC] [@ Abort | Could not load timezone service, brace yourself and prepare for crash | mozalloc_abort | NS_DebugBreak | cal::getTimezoneService] [@ cal::getTimezone…
(mv seems to be gone, killing NI) (In reply to Philipp Kewisch [:Fallen] from comment #9) > I think this is some race condition / startup ordering thing. > > The timezone service and/or the UTC timezone isn't loaded and is therefore > null, so I force a crash at that point. I currently can't reproduce this and > as my goal is to get rid of our C++ code, so I think we are going to have to > live with this for now. What component loads the service? Is it coming from NSPR?
Flags: needinfo?(cmv97) → needinfo?(philipp)
Some of the recent crashes are caused by testing the changes in Bug 1406499, see Bug 1406499 Comment 14.
See Also: → 1456577
(In reply to Stefan Sitter [:ssitter] from comment #19) > Some of the recent crashes are caused by testing the changes in Bug 1406499, > see Bug 1406499 Comment 14. Excellent. Somehow I had forgotten this, or missed it. It remains to be seen if the crash rate of 60.0b6 drops back to that of 60.0b3, which ranked ~#17
> > I think this is some race condition / startup ordering thing. > > > > The timezone service and/or the UTC timezone isn't loaded and is therefore > > null, so I force a crash at that point. I currently can't reproduce this and > > as my goal is to get rid of our C++ code, so I think we are going to have to > > live with this for now. > > What component loads the service? Is it coming from NSPR? This is an xpcom component. What we could do, which is a fugly hack, is to spin the event loop in case it is null at least for a few seconds, to see if it catches. What may be helpful is a js stack at the point where it crashes to see if something is accessing the timezone service before it is loaded.
Flags: needinfo?(philipp)
just a drive by comment - not surprising, v60 crash rate about the same, perhaps a little less. overall, ~38% German locale, ~38% win7 In v60, so far, all crashes are win10

Is this still an issue in 102?

Flags: needinfo?(vseerror)

seems to be long gone

Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(vseerror)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.