Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100925 Firefox/4.0b7pre SeaMonkey/2.1b1pre - Build ID: 20100925010142 and the Lightning nightly of the same date Reproducible: Every time. Steps to reproduce: 1. Upgrade to the next nightlies of SeaMonkey and Lightning. 2. Start up. Actual results: Crash at startup. No crash on Breakpad restart. Expected results: No crash at all. Additional info: bp-18fe6ef1-d47a-4b3a-9eb0-0a6ed2100924 bp-f1e4d5b1-b065-4ead-bc0e-23e822100925 I'm tentatively reporting this bug under "SeaMonkey integration" on the theory that if the tree is green, Lightning doesn't crash on Thunderbird. Please reclassify if appropriate. Similar crashes may still happen, but not at startup, on the 2nd, 3rd, etc. run of the program, but not as obvious to reproduce; see the crash IDs mentioned in several comments of bug 597908.

See also http://crash-stats.mozilla.com/report/list?product=SeaMonkey&product=Thunderbird&platform=windows&platform=mac&platform=linux&platform=solaris&query_search=signature&query_type=exact&query=js_ShareWaitingTitles&date=09%2F25%2F2010 11%3A48%3A18&range_value=1&range_unit=weeks&hang_type=crash&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=js_ShareWaitingTitles The Windows events are for another branch, probably strays. At least one user other than me (a Thunderbird user on Ubuntu) is crashing at the same signature, it might be interesting to know if (s)he uses Lightning.

This is ATM the top crasher for both Sm2.1b1pre (6) and Tb3.1a1pre (7) even though they only experience it on Linux so far.

Cannot confirm. No crash after installing Lightning 1.1a1pre (20100925) in Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100925 Firefox/4.0b7pre SeaMonkey/2.1b1pre.

(In reply to comment #3) > Cannot confirm. No crash after installing Lightning 1.1a1pre (20100925) in > Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100925 Firefox/4.0b7pre > SeaMonkey/2.1b1pre. Strange: I had it yesterday and I got it again today. Yesterday it happened more often, even on subsequent reloads, but gdata-provider was also enabled (today I left it disabled, even though I upgraded them both); also, today is a calm day for me: no calendar alarm has been triggered yet since the startup crash that I got immediately before reporting this bug. We'll see tomorrow if I crash again with the next nightly. This is of course only circumstantial evidence, but I just checked the latest Thunderbird crash with that signature, bp-51d1ee62-51c1-4fd4-83fd-348f52100925 -- and {e2fda1a4-762b-4020-b5ad-a41df1933103} i.e. Lightning was also among the enabled extensions. The list of 25 crashes at this signature during the last fortnight looks like two users are affected: me with SeaMonkey on openSUSE and another user with Thunderbird on Ubuntu.

So this is what has been crashing here in last few days! I do have Lightning installed, local build, but it shouldn't make much of a difference as patches I've got applied only touch UI and I've had them applied for a while while crashes only started recently. It seems that I crash 100% when starting up Thunderbird (no matter if Lightning has been installed right before or not) and sometimes when it has been running for a while. At times it crashes twice in a row. Thunderbird is Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100923 Thunderbird/3.3a1pre and Lightning is comm-central r4d36594ea0e8 and mozilla-central r9549708d2e90. Not sure if there's any other useful information I could provide, if there is, do ask!

bp-e4e92db9-fd5f-4984-b382-337332100926 while I was away sleeping. No alarm due. Lightning is set to refresh calendars every 60 minutes and obviously it can do it (at least sometimes) without crashing.

I notice that all crashes listed by Socorro for this signature are SEGV events at address zero. Trying to jump to dereference a NULL pointer?

oops: s/to jump//

oh, another guess: the first time I had this crash was when trying to install a lightning.xpi which had been "doctored" to include <em:unpack>true</em:unpack>, see bug 597908 comment #2 to #4. Maybe this is a Toolkit::AddonsManager bug with extensions insisting on being installed unpacked? But then, what about when this bug happens other than at startup? I'm still in the dark. Also, I have "legacy" extensions which were installed when all were unpacked, and not updated, and AFAICT they don't trigger this bug.

Two noticable things from bp-e4e92db9-fd5f-4984-b382-337332100926 (comment 6): 4 libmozjs.so JS_YieldRequest js/src/jsapi.cpp:917 5 libnspr4.so PR_AtomicDecrement nsprpub/pr/src/misc/pratom.c:312 6 libmozjs.so js_InvokeOperationCallback js/src/jscntxt.cpp:1894 why and how is nspr calling js? and: crashing thread has 0 libmozjs.so js_ShareWaitingTitles js/src/jslock.cpp:512 and thread 20: 1 libmozjs.so ClaimTitle js/src/jslock.cpp:628 I guess two threads are calling javascript, and both do something with titles. Maybe those two threads step on each others toes? Does this only happen on seamonkey?

(In reply to comment #10) [...] > Does this only happen on seamonkey? Not only: in the Thunderbird crash mentioned in the last paragraph of comment #4, ClaimTitle appears at levels 1 and 2 in the stack for thread 16.

(In reply to comment #4) > [...] We'll see tomorrow if I > crash again with the next nightly. [...] Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100926 Firefox/4.0b7pre SeaMonkey/2.1b1pre - Build ID: 20100926004737 Well, I did, bp-8b2776f7-55b8-42d3-9741-27b342100927 (yeah, this time I didn't rush to this nightly ;-) ) Stefan, I wonder what it is which makes Merike and I crash every time (at every startup and sometimes at other times too) and that AFAIK no one else can reproduce the bug. It's now 9:43 AM my time and I haven't slept yet: I'm going to bed. Next time I come here the first thing I'll do will be to refresh this bug. :-)

Have you tried a clean profile? Maybe there is some configuration setting or leftover from before libxul times that might cause trouble.

This seems to be happening to a few people, we should investiage this and find out why its crashing. I'll see if I can find someone from #jsapi to help out

(In reply to comment #13) > Have you tried a clean profile? Maybe there is some configuration setting or > leftover from before libxul times that might cause trouble. One of the very first things I tried (when I was still adding the <em:unpack> tag manually) was disabling everything but Lightning and gdata-provider, and it still crashed; but a really clean profile, not yet. However, how shall we find out what there is in my usual profile that makes us crash? Ideally, crashes should never happen. When I woke up, Breakpad was waiting for me, bp-b698364b-06d0-42e4-a125-928a62100927 -- the next thing I'm going to do with my "full" profile is disable Lightning to establish that I don't crash then; but it may take some time before I can be sure that there really is no crash.

I clicked "Disable" for Lightning, the EM told me it would be disabled after a restart, and then there was a crash, bp-19032045-3e27-41fa-9598-135ff2100927 . On restart from the crash, Lightning wasn't disabled after all. It seems I'll have to start into Safe Mode just for the privilege of disabling Lightning.

...and in SafeMode it tells me Lightning is going to be disabled at _next_ restart. :-? Let's click "Enable" then "Disable" just to make sure.

OK, here are the resuls of my "new profile" test; I typed all I did, step by step, in an editor: please bear with me. (The most interesting is at step 21, near the end.) An empty new profile is meaningless, so I tried to make the "Lightning" part of this new profile as close as possible to what I use normally. One problem with this approach is that all my calendars except two are private (either on my HDD, or the "private" URL, censored below, for a Google calendar). I hope it does not matter too much. 1. Start SeaMonkey with -ProfileManager, make new profile named test-lightning and use it. 2. In about:config, untick "Show «This may void your warranty» next time" and toggle browser.preferences.instantApply to false. 3. In "Edit => Preferences => Browser => Tabbed browsing", change 3 checkboxes ([√] = tick, [-] = untick) [-] Hide the tab bar when only one tab is open [√] Switch to new tabs opened from links [-] Open related tabs after current tab 4. Set the pref (in the "Advanced => Software installation" prefs, under "Allowed Websites" to allow ftp.mozilla.org to install extensions. 5. Both there and in the EM, set extensions _not_ to upgrade automatically. 6. Enable SeaMonkey Modern theme. 7. Install lightning and gdata-provider.xpi from http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/2010/09/2010-09-25-03-comm-central/linux-xpi/ 8. "Restart now" under Lightning in the addons manager List view. Confirm ("Restart now") in the popup. 9. Lightning and gdata-provider are now enabled. 10. Start Mail & Newsgroups. It wants me to define a M&N account, so define one for news.mozilla.org and subscribe to mozilla.announce. There are 132 messages, mark the whole NG read. 11. Open Lightning in a new tab. Open Lightning preferences (*bold* are what I change; checkboxes: √ yes, - no): * Main tab - Date format: Long, Tue 28 Sep 2010 - Default event length: *30* minutes - Default snooze length: 5 minutes - [√] Refresh calendars every *60* minutes - Select timezone: Europe/*Brussels* * Alarms - *[-]* Play a sound - [√] Show alarm box - [√] Show missed alarms - Default setting for events: *On* - Default setting for tasks: Off - Default time before an event: *90* minutes - Default time before a task: 5 minutes * Categories: add the following: - Doctor (no color) - Visitors (color:green) * Views - Start the week on *Monday* - Include in workweek: √Mon √Tue √Wed √Thu √Fri -Sat -Sun - Day starts at: 8:00 - Include 8 hours at a time - Day ends at: *Midnight* - Multiweek view: *5 weeks* - Previews weeks: None OK. 12. Select Multiweek view. Set events list to "Events in next 31 days", columns to Title - Start - End - Location - Calendar name and sort ▼ by starting date 13. Add calendars (describe all of them, even local ones, as "on the network" so I can point to existing ICS files). Never enable the "experimental cache" feature". * "Home Calendar" (ICS - default color - email:none - show alarms) file:///root/.download/mozilla/ext_sb/HomeCalendar.ics * "942" (ICS - blue - email:none - show alarms) file:///root/.download/mozilla/ext_sb/942.ics * "21 J&L" (ICS - dark red - email:none - show alarms) file:///root/.download/mozilla/ext_sb/21%20J&L.ics * "Pélican" (ICS - bright red - email:none - show alarms) file:///root/.download/mozilla/ext_sb/Pelican.ics * "Belgian-French Holidays" (ICS - yellow - email:none - don't show alarms) http://www.mozilla.org/projects/calendar/caldata/BelgianFrenchHolidays.ics -- then reopen its "Properties" to set it readonly * Mozilla Webdev (ICS - cyan - email:none - don't show alarms) https://mail.mozilla.com/home/morgamic@mozilla.com/Webdev%20Releases -- then reopen its "Properties" to set it readonly * "com_internet" (Google - light violet - email:antoine.mechelynck@gmail.com (default) - show alarms) [the "private" http address ending in basic.ics] -- this one gives an error, see bug 597908 comment #9, so redefine it as ICS on the same URL 8. Disable the default "Home" calendar and unsubscribe from it -- disabling works but unsubscribing doesn't work. ("Delete calendar" does nothing). So go to about:config and "reset" all prefs for the calendar whose URI is moz-storage-calendar:// . calendar-main-default and calendar-main-in-composite must first be toggled to false, otherwise they cannot be reset. 14. Install lightning and gdata-provider from http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-comm-central/linux-xpi/ 15. Open the "Available updates" panes of the addons manager. It shows Lightning and Provider for Google Calendar. Click "Restart now" for Lightning. 16. Confirm "Close all tabs" for Messenger. Confirm "Restart now" in the "Restart SeaMonkey" popup. --- No crash. But maybe I didn't restart the right way. 17. Install the latest lightning and gdata-provider hourly builds (in this case, from http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/tinderbox-builds/comm-central/linux-xpi-linux/1285626811/ (they are queued for update, do not restart yet). 18. Download the latest SeaMonkey hourly build (in this case, http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/comm-central-trunk-linux/1285627413/seamonkey-2.1b1pre.en-US.linux-i686.tar.bz2 ). 19. *Close* SeaMonkey (File => Quit, answer "Save and Quit" in the Quit popup, then wait for the seamonkey-bin process not to exist anymore). 20. rm -Rvf /usr/local/seamonkey && tar -jxvC /usr/local -f seamonkey-2.1b1pre.en-US.linux-i686.tar.bz2 21. Start SeaMonkey as "seamonkey -P test-lightning -browser -mail" --- this time there is a crash at startup, bp-b3c87a02-41f7-4b16-aedd-4a4802100927 22. Start SeaMonkey as "seamonkey -P default" (the same build, but on my usual profile) --- no crash.

oops. Error when renumbering comment #15: Line "8." between 13. and 14. should be "14." and everything after that should be one higher.

and oops of oops: s/#15/#18/ in comment #19. Sorry for the bugspam.

(In reply to comment #18) [...] > 20. rm -Rvf /usr/local/seamonkey && tar -jxvC /usr/local -f > seamonkey-2.1b1pre.en-US.linux-i686.tar.bz2 > 21. Start SeaMonkey as "seamonkey -P test-lightning -browser -mail" > --- this time there is a crash at startup, > bp-b3c87a02-41f7-4b16-aedd-4a4802100927 [...] Alas, apparently this "tinderbox-build" was compiled without symbols, or Socorro didn't bother to save them. I can only assume that libmozjs.so@0xa31e1 means js_ShareWaitingTitles

With Lightning disabled, this instance of SeaMonkey (started shortly before comment #18) didn't crash in my absence. Now I'm going to update to the 2010-09-28 nightly build of SeaMonkey (not an hourly so it'll have symbols); alas, no Calendar trunk nightly was built today, so let's grab the latest lightning and gdata-provider hourlies, enable them, and hope that they won't crash _too_ often. I still have Sunbird 1.0b2pre 2010-05-26 for if worse comes to worst.

Tony, could you comment out these lines and see if it still crashes: http://mxr.mozilla.org/comm-central/source/calendar/base/modules/calUtils.jsm#108 http://mxr.mozilla.org/comm-central/source/calendar/base/modules/calUtils.jsm#109

In reply to comment #22 Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100928 Firefox/4.0b7pre SeaMonkey/2.1b1pre - Build ID: 20100928004737 After three startup crashes in succession (the first and second times this bug crashed on me at Breakpad restart), I had to start in Safe Mode and disable Lightning. bp-c133f8e1-cd00-4207-aaee-1f8d22100928 bp-a6c15df4-369f-4305-8b76-194782100928 bp-2f2e04ca-0c5a-4dcb-a5f9-207a02100928 all three [@ FinishSharingTitle ] [@ js_ShareWaitingTitles ] SEGV @ 0x4

the above was posted (comment only) in mid-air collision with comment #23. Let us have a look at that mxr link...

Philipp, after replacing the spaces by slashes in columns 1-2 of these two lines (thus making cal_processPendingEvent() a no-op IIUC) and restarting with that "doctored" Lightning enabled, I get no startup crash (with otherwise the same Sm+L+GDP build as in comment #24). I'm letting it run, so if there is a later crash it will get caught.

hm, if this is the cause (and I get no crash until and including when I restart from installing tomorrow's nightlies with the fix [possibly manually] in them), then it would mean a flaw in the fix for bug 387014 ...

...however, that fix dates from May 2009 and the bug started happening nine days ago AFAICT. Maybe there is more to it...

The session started just before comment #26 just crashed, plus two breakpad-startup crashes: three in succession is my limit, I'm in Safe Mode, about to restart with Lightning disabled. :-( bp-bc6ac2db-feb6-4957-8a4c-ce00c2100928 bp-4721d782-5b39-46d3-9261-e67dc2100928 bp-477b891b-236f-4ede-aa70-3db5a2100928 -- same signature as in comment #24

Some of the JSAPI branches (tracemonkey/jaegermonkey) recently were merged with mozilla-central, which may expose these issues. I hope to get rid of spinning the event loop in bug 494788. I've been told that crashing in FinishSharingTitle is where the object pointer is "figured out" by going backwards from the title pointer. We might want to file a jsapi bug on this, but it would be nice to have a reduced testcase (i.e an extension that spins the event loop until it crashes)

This is not only Lightning only, and not only Linux. This FinishSharingTitle crash signature exists also in Firefox 4.0b7pre on Windows only. It is #51 top crasher in 4.0/b7pre for the last week. The js_ShareWaitingTitles crash signature exists also in Firefox 4.0b7pre on Mac OS X/Linux only. It is #285 top crasher in 4.0/b7pre for the last week. Both signatures happen mainly at start-up. According to me, it is a Javascript issue. The regression range for FinishSharingTitle crash signature is : http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c257bfb8cad0&tochange=a60414d076b5 More reports for FinishSharingTitle signature at: http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=FinishSharingTitle&version=Firefox%3A4.0b7pre More reports for ShareWaitingTitles signature at: http://crash-stats.mozilla.com/report/list?range_value=4&range_unit=weeks&signature=js_ShareWaitingTitles&version=Firefox%3A4.0b7pre

"Nice to hear" this is not only Lightning. I'd appreciate this being accepted as a 2.0 blocker.

I've been thinking about those titles. Before the crash started happening, and with Lightning enabled, the current date used to appear briefly at startup in the title of the 3-pane window. It was then replaced by the name of the current mail folder. This "current folder" is not Inbox because I have the "Folderpane Tools" extension set to start Mail in the Junk folder rather than in Inbox. (I also have "MR-Tech Toolkit" set to add some stuff at the end of window titles, as a replacement for "SeaMonkey {BuildID}", but ATM that seems to work only in the Browser, not in the Mailer.) Is it possible to remove the line(s) which sets the 3-pane window title to the current date at startup? If that line is pointed to me, I'm willing to comment it out to see if I still get the crash. Of course the wider problem of "something in Core" causing the crash should still be fixed (but when?) regardless of whether we succeed to "plaster up the damage" in Calendar.

Signature FinishSharingTitle UUID bc6ac2db-feb6-4957-8a4c-ce00c2100928 Time 2010-09-28 22:43:32.907735 Uptime 21632 Last Crash 27550 seconds (7.7 hours) before submission Install Age 27873 seconds (7.7 hours) since version was first installed. Product SeaMonkey Version 2.1b1pre Build ID 20100928004737 Branch 2.0 OS Linux OS Version 0.0.0 Linux 2.6.34.7-0.3-desktop #1 SMP PREEMPT 2010-09-20 15:27:38 +0200 i686 CPU x86 CPU Info AuthenticAMD family 6 model 7 stepping 1 Crash Reason SIGSEGV Crash Address 0x4 User Comments thinking on what to do next, in the Forecastfox forum Processor Notes EMCheckCompatibility False Related Bugs Crashing Thread Frame Module Signature [Expand] Source 0 libmozjs.so FinishSharingTitle js/src/jslock.cpp:513 1 libmozjs.so js_ShareWaitingTitles js/src/jslock.cpp:652 2 libmozjs.so StopRequest js/src/jsapi.cpp:878 3 libmozjs.so JS_SuspendRequest js/src/jsapi.cpp:934 4 libxul.so JSAutoSuspendRequest::JSAutoSuspendRequest 5 libxul.so XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:3083 6 @0x78bfe4c7 7 libxul.so XPCWrappedNative::GetAttribute js/src/xpconnect/src/xpcprivate.h:2569 8 libxul.so XPC_WN_GetterSetter js/src/xpconnect/src/xpcwrappednativejsops.cpp:1799 9 libmozjs.so js::Invoke js/src/jscntxtinlines.h:657 10 libmozjs.so js::ExternalInvoke js/src/jsinterp.cpp:622 11 libmozjs.so js::ExternalGetOrSet js/src/jsinterp.h:910 12 libmozjs.so js_NativeGet js/src/jsscopeinlines.h:216 13 libmozjs.so js_GetPropertyHelper js/src/jsobj.cpp:5037 14 libmozjs.so js::Interpret js/src/jsinterp.cpp:3864 15 libmozjs.so js::Invoke js/src/jsinterp.cpp:484 16 libmozjs.so js::ExternalInvoke js/src/jsinterp.cpp:622 17 libmozjs.so JS_CallFunctionValue js/src/jsinterp.h:910 18 libxul.so nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1692 19 libxul.so nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:571 20 libxul.so PrepareAndDispatch xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:95

This seems to only appear in 3.* versions. Resolving as works for me.