Closed Bug 675608 Opened 13 years ago Closed 13 years ago

startup crash [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()]

Categories

(Calendar :: General, defect)

x86_64
Windows 7
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wsmwk, Assigned: Fallen)

References

()

Details

(Keywords: crash, regression, topcrash, Whiteboard: [gs])

Crash Data

Attachments

(1 file)

startup crash [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()]

regression - crashes start on july 31 with calendar 1.0b5 - https://crash-stats.mozilla.com/report/list?product=Thunderbird&query_search=signature&query_type=exact&query=mozalloc_abort%28char%20const%2A%20const%29%20%7C%20NS_DebugBreak_P%20%7C%20cal%3A%3AgetTimezoneService%28%29&reason_type=contains&date=08%2F01%2F2011%2006%3A09%3A42&range_value=4&range_unit=weeks&hang_type=any&process_type=all&do_query=1&signature=mozalloc_abort%28char%20const%2A%20const%29%20%7C%20NS_DebugBreak_P%20%7C%20cal%3A%3AgetTimezoneService%28%29

caused by bug 603416?


reporter on getsatisfaction http://getsatisfaction.com/mozilla_messaging/topics/thunder_bird_5_having_monday_morning_itis
bp-2fb5b3c4-514f-4b91-881c-97a622110801
EXCEPTION_BREAKPOINT
0x6346111b
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
Flags: blocking-calendar1.0?
topcrash after 2 days
Keywords: topcrash
This crash was uncovered by the fix, I had added some debug statements that make it crash more controlled:

ABORT: Could not load timezone service, brace yourself and prepare for crash: file e:\buildbot\comm-miramar-lightning-release\comm-miramar\calendar\base\src\calUtils.h

So at least we now know the timezone service could not be loaded, but why this happens I do not know. The place this happens is:

http://mxr.mozilla.org/comm-central/source/calendar/base/src/calUtils.h#143

The timezone service itself doesn't do anything spectacular in its constructor, so TBH I have no idea why it fails that that point:

http://mxr.mozilla.org/comm-central/source/calendar/base/src/calTimezoneService.js#106

The only thing I can imagine is that something is strange with the timezone service itself. When you enable javascript.options.strict, then you get a lot of messages that UTC/defaultTimezone/floating is not defined. If we find the root cause of this I can imagine that this might also go away.
FWIW, I got this immediately after the auto-update from beta4 to beta5. I removed beta5, restarted t-bird, then installed beta5 from the t-bird website, and restarted beta5 again.  This seems to have fixed it, so it's quite likely an update problem of some kind.
If we've got anyone who can reproduce, then finding out what that rv variable at the crash site may be helpful.

Is the timezone service now closely integrated with Lighting? At one time I thought there was a separate timezone install.rdf and things around.
Keywords: qawanted
Yeah, could it be someone else's timezone service with the same contract ID messing things up? What if we change the contract ID and then see what happens? That's really the only thing I can think of here...
(an interesting observation would be trying to correlate it with the presence of a different extension)
(In reply to comment #7)
> (an interesting observation would be trying to correlate it with the
> presence of a different extension)

I examined 10 TB5 dumps whose uptime should be sufficient to reveal the extension list.
3 listed no extensions
3 list only lightning bp-aea50eba-c8d5-4bb8-bb6c-c2df12110803 bp-e975d283-e926-4f5d-a214-1bf012110804 bp-11852eda-22e2-4cff-a113-797e62110803
most of the remaining 4 have nothing interesting bp-49098c19-bb0e-4f29-a20e-758762110804 bp-925f828a-963b-4bca-a894-dc99a2110804 bp-a5cee227-b87d-4694-9cb0-a7a492110804 bp-e9b32eb1-b284-45d3-a4e8-e68dd2110804

TB6 example bp-29caa461-40b1-4338-aa17-fe8652110731
NB this report - http://getsatisfaction.com/mozilla_messaging/topics/thunder_bird_5_having_monday_morning_itis#reply_6255087
"I got the same problem after auto-updating from b4 to b5. I removed b5, restarted tbird, then installed b5 from fresh d/l, and restarted again. Problem has now gone"

so perhaps this is an addon installation issue?
The timezone extension only contains the binary data for the timezones, the timezone service is part of core Lightning, so it should be there no matter what. 

A bunch of installation issues were reported, which is a bummer. Those may have to do with bug 666896, when the user cancels the slow script warning or possible kills Thunderbird at the wrong point, it will result in a half-installed extension that contains missing files. To "solve" this I had the build system put the locales into packed .jar files, which reduced filesize by 1MB and therefore quickens the unpack speed.
(In reply to comment #9)
> NB this report -
> http://getsatisfaction.com/mozilla_messaging/topics/
> thunder_bird_5_having_monday_morning_itis#reply_6255087
> "I got the same problem after auto-updating from b4 to b5. I removed b5,
> restarted tbird, then installed b5 from fresh d/l, and restarted again.
> Problem has now gone"
> 
> so perhaps this is an addon installation issue?

Yeah, that was my report.  For the record I have only 2 extensions to tbird:
Lightning 1.05b and 
Enigmail 1.2

Additionally the following plugins:
ActiveTouch General Plugin Container 2.7.0.7
Adobe Acrobat 10.0.1.434
Java Deployment Toolkit 6.0.260.3
Java Platform SE 6 U26 6.0.260.3
Shockwave Flash 10.3.181.26
Windows Presentation Foundation 3.5.30729.1
Yahoo Application State Plugin 1.0.0.7

I saw no difficulties when the auto update occurred.
bp-0f85c2c6-3dd8-4dd5-a64f-4c9b02110803 (Peggy) writes

"It worked fine till I tried to change the theme."
Blocks: 603416
Summary: startup crash [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()' → startup crash [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | cal::getTimezoneService()]
One, or possibly more two people used the same workaround as comment 9, "start thunderbird in safe mode and disable lightning. I could then start fine without safe mode. I removed lightning, restarted, reinstalled it, restarted, and it's continued to work fine ever since." per http://getsatisfaction.com/mozilla_messaging/topics/thunder_bird_5_having_monday_morning_itis#reply_6288455
I guess we could make a missing timezone service disable Lightning and ask the user to remove and reinstall it, but is that worth the effort? The timezone service is quite deep down, so it might be a lot of work.
Is comment 13 likely to be a reliable workaround?
And is there a simpler workaround?
still need workaround for users who see this.
still thunderbird's #1 crash.

crash goes back to TB5. But apparently some users didn't see it back that far. For example some users it in version 7 but didn't it in version 6.
Attached patch Possible Fix - v1 β€” β€” Splinter Review
I just had this situation for my comm-central build on mac. It just happened randomly and didn't want to go away. After lots of back and forth it just worked at some point.

While debugging I found out that in my case all C++ components worked without flaws, but the JS components all failed to load. I put the timezone service into its own component, but this didn't help. It wasn't a debug build, but I could find out that the actual error that causes getService to fail occurs here:

http://hg.mozilla.org/mozilla-central/annotate/3b58a9df4c8c/xpcom/components/nsComponentManager.cpp#l1220

This patch moves the timezone service into its own component and is no guarantee for fixing it, but after I got everything right with component registration, it magically fixed itself. I'm not sure if thats because of this change or just a coincidence.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #567283 - Flags: review?(matthew.mecca)
Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/5b97fe84948c>
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Trunk
Comment on attachment 567283 [details] [diff] [review]
Possible Fix - v1

Looks OK codewise, I haven't encountered this crash so I'm not sure if it fixes the issue or not. r=mmecca
Attachment #567283 - Flags: review?(matthew.mecca) → review+
Damnit, I was so sure I pushed this to comm-aurora and beta too :-( Now this patch missed rc2. Backporting now...
Backported to comm-aurora <http://hg.mozilla.org/releases/comm-aurora/rev/299483b7c0ba>
Target Milestone: Trunk → 1.0b9
Backported to comm-beta <http://hg.mozilla.org/releases/comm-beta/rev/66f80c42268e>
Target Milestone: 1.0b9 → 1.0b8
requested testing in http://getsatisfaction.com/mozilla_messaging/topics/thunder_bird_5_having_monday_morning_itis and with several crash reporters to use 10/25 nightly builds ... awaiting feedback
tests so far with Daily or Aurora ...
5-6 people have reported success.
none have reported failure.
Blocks: 700827
Removing blocking-request and qawanted as there is follow-up bug 700827.
Flags: blocking-calendar1.0?
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.