599637 - crashes at first startup after install or upgrade [@ FinishSharingTitle ] [@ js_ShareWaitingTitles ]

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Tony Mechelynck [:tonymec]]

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.

Comment 1

[Tony Mechelynck [:tonymec]]

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.

Comment 2

[Tony Mechelynck [:tonymec]]

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.

Comment 3

[Stefan Sitter [:ssitter]]

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.

Comment 4

[Tony Mechelynck [:tonymec]]

(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.

Comment 5

[Merike Sell (:merike)]

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!

Comment 6

[Tony Mechelynck [:tonymec]]

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.

Comment 7

[Tony Mechelynck [:tonymec]]

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?

Comment 8

[Tony Mechelynck [:tonymec]]

oops: s/to jump//

Comment 9

[Tony Mechelynck [:tonymec]]

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.

Comment 10

[Michiel van Leeuwen (email: mvl+moz@)]

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?

Comment 11

[Tony Mechelynck [:tonymec]]

(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.

Comment 12

[Tony Mechelynck [:tonymec]]

(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. :-)

Comment 13

[Stefan Sitter [:ssitter]]

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

Comment 14

[Philipp Kewisch [:Fallen][📱📆]]

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

Comment 15

[Tony Mechelynck [:tonymec]]

(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.

Comment 16

[Tony Mechelynck [:tonymec]]

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.

Comment 17

[Tony Mechelynck [:tonymec]]

...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.

Comment 18

[Tony Mechelynck [:tonymec]]

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/[e-mail]/Webdev%20Releases
    -- then reopen its "Properties" to set it readonly
  * "com_internet" (Google - light violet - email:[e-mail] (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.

Comment 19

[Tony Mechelynck [:tonymec]]

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

Comment 20

[Tony Mechelynck [:tonymec]]

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

Comment 21

[Tony Mechelynck [:tonymec]]

(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

Comment 22

[Tony Mechelynck [:tonymec]]

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.

Comment 23

[Philipp Kewisch [:Fallen][📱📆]]

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

Comment 24

[Tony Mechelynck [:tonymec]]

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

Comment 25

[Tony Mechelynck [:tonymec]]

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

Comment 26

[Tony Mechelynck [:tonymec]]

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.

Comment 27

[Tony Mechelynck [:tonymec]]

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 ...

Comment 28

[Tony Mechelynck [:tonymec]]

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

Comment 29

[Tony Mechelynck [:tonymec]]

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

Comment 30

[Philipp Kewisch [:Fallen][📱📆]]

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)

Comment 31

[Scoobidiver (away)]

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

Comment 32

[Philipp Kewisch [:Fallen][📱📆]]

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

Comment 33

[Tony Mechelynck [:tonymec]]

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.

Comment 34

[timeless]

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

Comment 35

[Sheila Mooney]

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