crash after Firefox or Thunderbird checks for Extension/Theme updates - Trunk FF11a1 TB11a1 [@ firefox-bin][@ thunderbird-bin]

RESOLVED FIXED in mozilla1.8final

Status

()

Toolkit
Application Update
--
blocker
RESOLVED FIXED
13 years ago
6 years ago

People

(Reporter: marcia, Assigned: Benjamin Smedberg)

Tracking

({crash, topcrash})

Trunk
mozilla1.8final
PowerPC
Mac OS X
crash, topcrash
Points:
---
Bug Flags:
blocking1.8b2 -
blocking1.8b3 +
blocking-aviary1.5 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(4 attachments)

Seen using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2)
Gecko/20050527 Firefox/1.0+

Using an existing profile, STR:

1.  After installing application, you get the dialog box that asks you if you
want to check for updates to themes/extensions.
2.  Click "don't check"
3.  Immediate crash

If you decide to check, it will go out and find updates and install them, but
will still crash.

TB id is TB6175930M
Component: General → Software Update
QA Contact: general → software.update
alas, not a useful stack afaict...

Incident ID: 6175930
Stack Signature	firefox-bin + 0x2d0b80 (0x002d0b80) 6908b317
Product ID	FirefoxTrunk
Build ID	2005052707
Trigger Time	2005-05-27 10:34:09.0
Platform	MacOSX
Operating System	Darwin 7.9.0
Module	firefox-bin + (002d0b80)
URL visited	
User Comments	Crashed after dialog came up asking about whether I wanted to
check for updates to existing extensions.
Since Last Crash	289 sec
Total Uptime	289 sec
Trigger Reason	SIGBUS: Bus Error: (signal 10)
Source File, Line No.	N/A
Stack Trace 	
firefox-bin + 0x2d0b80 (0x002d0b80)
firefox-bin + 0x2d0b4c (0x002d0b4c)
firefox-bin + 0x5635cc (0x005635cc)
firefox-bin + 0x636c3c (0x00636c3c)
firefox-bin + 0x63590c (0x0063590c)
firefox-bin + 0x631094 (0x00631094)
nsObserverService::NotifyObservers()
NS_ShutdownXPCOM_P()
firefox-bin + 0x7ff59c (0x007ff59c)
firefox-bin + 0x803378 (0x00803378)
firefox-bin + 0xf69c (0x0000f69c)
firefox-bin + 0xf51c (0x0000f51c)
Important to note that I had a number of "older" extensions installed in my
profile that needed to be updated. After the crash I was able to relaunch, and
all of those extensions were disabled.
Flags: blocking-aviary1.1?

Updated

13 years ago
Flags: blocking1.8b2+
This is the same error as in bug 
> This is the same error as in bug 

which bug #?
Sorry, that last partial comment was meant for bug 295732
I highly suspect this is related to bug 292823 and it may be possible to fix the
crash condition by QI'ing nsIDirectoryEnumerator consistently in
nsExtensionManager.js.in specifically at 
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#1103
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#1111
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#1696
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#5522

Regretfully, I don't have a Mac handy to test this out.
Created attachment 184726 [details]
Apple crash reporter
Could someone with a Mac verify this?
Start with a new profile with no extensions.
Drop any extension xpi into the profiles directory.
Restart Deer Park
I get a crash when I do this which is likely the same crash as this bug.
It appears that nsIDirectoryEnumerator is not the cause. I tested upgrading and
downgrading using a current build and a build from 20050429. When downgrading to
the 20050429 build it also brought up the check for updates ui and also caused a
crash. When commenting out the code that opens this window at:
http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/update/src/nsUpdateService.js.in#254
it no longer crashes. I also early returned in the init and uninit functions in
the JS for this window and it still crashed with just closing the window.

Since the upgrade code only runs during a version bump this may have regressed
over a large span of time. Also, to go any further with this I would need a Mac
build environment and I am borrowing the Mac I used for testing so this isn't an
option for me.
(Assignee)

Comment 10

13 years ago
Marcia, does talkback come up in this crash? Is it possible to get a talkback
stack? The CrashReporter log is interesting but does not have local var information.
Flags: blocking-aviary1.1? → blocking-aviary1.1+
(Assignee)

Comment 11

13 years ago
In the "steps to reproduce", is the "existing profile" a 1.0.x profile or a
fresh profile created with a trunk build?
Benjamin: This is an existing profile that I have been using back to the 1.0
days. Josh actually took a snapshot of my profile and was not able to crash on
his Mac machine.

I reported a few stack traces (see Comments 1 and 2), but Sarah indicated that
they weren't really useful.
Robert: Did you get a talkback ID with this?

(In reply to comment #8)
> Could someone with a Mac verify this?
> Start with a new profile with no extensions.
> Drop any extension xpi into the profiles directory.
> Restart Deer Park
> I get a crash when I do this which is likely the same crash as this bug.

Comment 14

13 years ago
lets figure this out in b3
Flags: blocking1.8b3+
Flags: blocking1.8b2-
Flags: blocking1.8b2+
(In reply to comment #13)
> Robert: Did you get a talkback ID with this?
> 
> (In reply to comment #8)
> > Could someone with a Mac verify this?
> > Start with a new profile with no extensions.
> > Drop any extension xpi into the profiles directory.
> > Restart Deer Park
> > I get a crash when I do this which is likely the same crash as this bug.
> >
Talback didn't launch for me. I just noticed one mistake in how to reproduce.
The xpi needs to be dropped in the profile's extensions directory.
Blocks: 296357
a not so useful talkback just created when reproducing this bug
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB6576294E
it looks like this is becoming one of the top 10 crashers for deer park,
especially on Mac OS X.

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=firefox-bin&vendor=MozillaOrg&product=FirefoxTrunk&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

here is a snippet from the Talkback topcrash smart analysis report:

Rank   StackSignature   Count  
-----------------------------
1      firefox-bin      170 
====================================================================================================
     Count   Offset    Real Signature
[ 137   firefox-bin + 0x2d0bf8 (0x002d0bf8) b4a30feb - firefox-bin + 0x2d0bf8
(0x002d0bf8) ]
 
     Crash date range: 01-JUN-05 to 11-JUN-05
     Min/Max Seconds since last crash: 9 - 417706
     Min/Max Runtime: 9 - 499010
 
     Count   Platform List 
     82   [Darwin 8.1.0]      
     50   [Darwin 7.9.0]      
     3   [Darwin 7.8.0]      
     2   [Darwin 8.0.0]      
 
     Count   Build Id List 
     137   2005053112
 
     No of Unique Users       100
 
 Stack trace(Frame) 

	 firefox-bin + 0x2d0bf8 (0x002d0bf8)  
	 firefox-bin + 0x2d0bc4 (0x002d0bc4)  
	 firefox-bin + 0x563694 (0x00563694)  
	 firefox-bin + 0x636d04 (0x00636d04)  
	 firefox-bin + 0x6359d4 (0x006359d4)  
	 firefox-bin + 0x63115c (0x0063115c)  
	 nsObserverService::NotifyObservers()  
	 NS_ShutdownXPCOM_P()  
	 firefox-bin + 0x7ff664 (0x007ff664)  
	 firefox-bin + 0x803440 (0x00803440)  
	 firefox-bin + 0xf69c (0x0000f69c)  
	 firefox-bin + 0xf51c (0x0000f51c)   
 
     (6589302)	Comments: I was starting DeerPark and the it checked new version
of some extentions because they were uncompatible with it. After some seconds 
it crashed...
     (6576825)	Comments: Loading it after just quitting firefox 1.0.4
     (6564169)	Comments: Running Deer Park Alpha on Mac OS 10.4 with an iMac G5
rev2 it came up with a window saying some extensions were incompatable then crashed
     (6559452)	Comments: launching the browser
     (6559079)	Comments: Upgrading extensions
     (6530830)	Comments: updating tabrowser to the last version
     (6494027)	Comments: installing the eb developer plugin. crashed on quitting
after install (severeal non-compatible plugins exisiting)
     (6483370)	Comments: starting the app for a second time. first time it ran
fine firefox had been run in between the first and second run if that makes a
diffecence.
     (6482608)	Comments: Had just finished dismissing the incompatible plugins
dialog box
     (6456545)	Comments: It crashed on start up after asking to check for
upgrades on two extensions(which didn't have upgrades for Deerpark)
     (6434847)	Comments: starting up; no action taken  except to respond to
component update dialog
     (6413504)	Comments: While starting the browser it checked for incompatible
extentions. It found Bookmarks Synchronizer 1.1. After checking for a new
version of the plugin the browser crashed. Restarting it worked.
     (6407917)	Comments: searching for a smoothwhell update
     (6373272)	Comments: started deer park alpha 1 and crash occured before
browser window opened  although I did get the "old extensions" dialog and had
clicked "get updates" and was told that none were found  and I clicked OK. 
That's when the crash happened.
     (6368000)	Comments: Launched Firefox first then noticed Deer Park couldn't
load. Loaded Deer Park again and it said an extension I had "CTA maps google"
that was not compatible then it crashed.
     (6356955)	Comments: 1. Started Deer Park Alpha1 2. Closed Deer Park Alpha1
3. Started Firefox 1.0.4 4. Closed Firefox 1.0.4 5. Started Deer Park Alpha1
     (6353775)	Comments: started Deer Park a  and it noted that some of the
plugins were incompatible
     (6343076)	Comments: Updating Firefox extensions.  It told me to restart 
but before I could  it crashed.
     (6328233)	Comments: Starting up. Firefox asked me to update incompatible
old versions of extensions  then checked and found no new versions. It then crashed.
Keywords: topcrash
Summary: [Mac] crash after Firefox checks for Extension/Theme updates → crash after Firefox checks for Extension/Theme updates - Trunk TB11a1 [@ firefox-bin]

Updated

13 years ago
Assignee: nobody → joshmoz

Comment 18

13 years ago
Created attachment 186610 [details]
backtrace from the crash in gdb - much more helpful

Comment 19

13 years ago
Here is the text from above the backtrace I attached:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x073bd85c in nsGlobalWindow::SetNewDocument (this=0x1df31a0, aDocument=0x0, 
aRemoveEventListeners=1, aClearScopeHint=1) at /Users/josh/src/ff_debug/mozilla/dom/src/base/
nsGlobalWindow.cpp:607
607                 nsIDOMNavigator* navigator =
(gdb) l
602             // clear timeouts and clear the scope
603             ClearAllTimeouts();
604
605             if (mContext && mJSObject) {
606               if (mNavigator) {
607                 nsIDOMNavigator* navigator =
608                   NS_STATIC_CAST(nsIDOMNavigator*, mNavigator.get());
609                 nsContentUtils::XPConnect()->
610                   WrapNative(cx, mJSObject, navigator, NS_GET_IID(nsIDOMNavigator),
611                              getter_AddRefs(mNavigatorHolder));

Comment 20

13 years ago
Blake and I can't find anything that is null near where gdb is saying the problem is. Over to someone who 
knows this kind of code better -> beng@google.com
these are starting to creep in the talkback reports for Thunderbird ().

Rank    StackSignature    Count  
1       thunderbird-bin   14 
====================================================================================================
     Count   Offset    Real Signature
[ 11   thunderbird-bin + 0x268100 (0x00268100) 9bb8be97 - thunderbird-bin +
0x268100 (0x00268100) ]
 
     Crash date range: 07-JUN-05 to 16-JUN-05
     Min/Max Seconds since last crash: 13 - 179656
     Min/Max Runtime: 14 - 180247
 
     Count   Platform List 
     9   [Darwin 8.1.0]      
     2   [Darwin 7.9.0]      
 
     Count   Build Id List 
     11   2005053113
 
     No of Unique Users         2
 
 Stack trace(Frame) 

	 thunderbird-bin + 0x268100 (0x00268100)  
	 thunderbird-bin + 0x2680cc (0x002680cc)  
	 thunderbird-bin + 0x53e4d4 (0x0053e4d4)  
	 thunderbird-bin + 0x865acc (0x00865acc)  
	 thunderbird-bin + 0x535f58 (0x00535f58)  
	 thunderbird-bin + 0x817f4 (0x000817f4)  
	 nsObserverService::NotifyObservers()
[/builds/tinderbox/Tb-Trunk/Darwin_7.8.0_Depend/mozilla/xpcom/ds/nsObserverService.cpp
 line 848] 
	 NS_ShutdownXPCOM_P()
[/builds/tinderbox/Tb-Trunk/Darwin_7.8.0_Depend/mozilla/xpcom/build/nsXPComInit.cpp
 line 770] 
	 thunderbird-bin + 0xab4c (0x0000ab4c)  
	 thunderbird-bin + 0xe928 (0x0000e928)  
	 thunderbird-bin + 0xa010 (0x0000a010)  
	 thunderbird-bin + 0x9e90 (0x00009e90)   
 
     (6724199)	Comments: startup. this time I went through the component update
check  but it still crashed.
     (6697407)	Comments: startup crash  after dismissing "don't check" the
"Incompatible components" dialog.
     (6665346)	Comments: started up
     (6633612)	Comments: tried starting it up from desktop. always seems to
crash on first start  then opens fine on restart.
     (6526884)	Comments: tried starting it up and told it not to check for
updates  then boom
Summary: crash after Firefox checks for Extension/Theme updates - Trunk TB11a1 [@ firefox-bin] → crash after Firefox or Thunderbird checks for Extension/Theme updates - Trunk FF11a1 TB11a1 [@ firefox-bin][@ thunderbird-bin]

Comment 22

13 years ago
we don't need any more crash reports at this point  - thanks

Updated

13 years ago
Assignee: joshmoz → benjamin
(Assignee)

Comment 23

13 years ago
Created attachment 186966 [details] [diff] [review]
New-doc check, rev. 1

There are several options here, and I am not nearly knowledgeable to decide
what option might cause what problems, so jst needs to pick.

option 0 involves null-checking nsContentUtils::XPConnect directly, but that
seems way too gross ;-)

option 1 involves null-checking the *new* aDocument, and not bothering to save
the old navigatorholder if it's null. dbaron and I weren't sure under what
situations other than closing the window completely SetNewDocument might be
called with null.

option 2 involves clearing the navigator object before calling SetNewDocument
(is this kosher?, I haven't written the patch yet) which skips this whole block
of code.
(Assignee)

Updated

13 years ago
Attachment #186966 - Flags: superreview?(jst)
Attachment #186966 - Flags: review?(jst)
Comment on attachment 186966 [details] [diff] [review]
New-doc check, rev. 1

SetNewDocument() is called with a null document every time we go from document
to document, and AFAIK, it's *never* called with a non-null document when
mDocument is non-null. So all this patch does is to never make us grab the
reference to the navigator object to restore once we get a new document.

Maybe we need to check for !mIsClosed (or !mDocShell) there instead?
Attachment #186966 - Flags: superreview?(jst)
Attachment #186966 - Flags: superreview-
Attachment #186966 - Flags: review?(jst)
Attachment #186966 - Flags: review-
(Assignee)

Comment 25

13 years ago
Created attachment 187084 [details] [diff] [review]
Null-check XPConnect() directly, rev. 1

Got r+sr from jst, a=drivers
Attachment #187084 - Flags: superreview+
Attachment #187084 - Flags: review+
Attachment #187084 - Flags: approval-aviary1.1a2+
(Assignee)

Comment 26

13 years ago
Fixed on trunk with the xpconnect null-check patch.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.1
Product: Firefox → Toolkit
Crash Signature: [@ firefox-bin] [@ thunderbird-bin]
You need to log in before you can comment on or make changes to this bug.