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

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Marcia Knous [:marcia]]

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

Comment 1

[sairuh (rarely reading bugmail)]

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)

Comment 2

[Marcia Knous [:marcia]]

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.

Comment 3

[Robert Strong (they/them - no direct email)]

This is the same error as in bug 

Comment 4

[sairuh (rarely reading bugmail)]

> This is the same error as in bug 

which bug #?

Comment 5

[Robert Strong (they/them - no direct email)]

Sorry, that last partial comment was meant for bug 295732

Comment 6

[Robert Strong (they/them - no direct email)]

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.

Comment 7

[Marcia Knous [:marcia]]

Attachment: Apple crash reporter

Comment 8

[Robert Strong (they/them - no direct email)]

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 9

[Robert Strong (they/them - no direct email)]

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.

Comment 10

[Benjamin Smedberg]

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.

Comment 11

[Benjamin Smedberg]

In the "steps to reproduce", is the "existing profile" a 1.0.x profile or a
fresh profile created with a trunk build?

Comment 12

[Marcia Knous [:marcia]]

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.

Comment 13

[Marcia Knous [:marcia]]

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

[chris hofmann]

lets figure this out in b3

Comment 15

[Robert Strong (they/them - no direct email)]

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

Comment 16

[Robert Strong (they/them - no direct email)]

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

Comment 17

[sairuh (rarely reading bugmail)]

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.

Comment 18

[Josh Aas]

Attachment: backtrace from the crash in gdb - much more helpful

Comment 19

[Josh Aas]

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

[Josh Aas]

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 -> [e-mail]

Comment 21

[sairuh (rarely reading bugmail)]

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

Comment 22

[Josh Aas]

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

Comment 23

[Benjamin Smedberg]

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

Comment 24

[Johnny Stenback (: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?

Comment 25

[Benjamin Smedberg]

Attachment: Null-check XPConnect() directly, rev. 1

Got r+sr from jst, a=drivers

Comment 26

[Benjamin Smedberg]

Fixed on trunk with the xpconnect null-check patch.