247054 - FF091 crash when clicking Options -> Downloads in Option Dialog [@ CompositeEnumeratorImpl::HasMoreElements ]

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P1)

Description

[Daniel Haas]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

After upgrading from Mozilla 0.8 to 0.9: (using migration wizard)
If I go to Tools -> Options and then click on "Downloads" Mozilla crashes. It
happens every time. So I cannot change any download options. :-(

Reproducible: Always
Steps to Reproduce:
1. Install Firefox 0.8
2. Change some download options under Tools -> Options : Downloads
3. Use Firefox 0.8 some time
4. Install some extensions (e.g. tabbrowser extension)
5. Wait for Firefox 0.9 to be released
6. Install Firefox 0.9 
7. Migrate configuration from Firefox 0.8 via wizard
8. Open Tools -> Options
9. Click on "Downloads"
10. See crash window :-)

Actual Results:  
A crash window shows up. After clicking ok. Firefox is gone.

Expected Results:  
Show the Downloads configuration as in previous version.

Also Submitted a Talkback. Incident ID: TB95673E

Comment 1

[José Jeria]

Did you uninstall 0.8 before installing 0.9?

Comment 2

[Daniel Haas]

(In reply to comment #1)
> Did you uninstall 0.8 before installing 0.9?

No, but i installed 0.9 in a fresh/new folder. Is this a problem?

Comment 3

[Dimitrios]

since old extensions were previously installed, a new profile will probably
resolve the problem.

Comment 4

[Michael Thome]

BTW - I see the same issue (segv) on an upgrade from 0.8 to 0.9.1 (x86, linux).

IMHO, given that one of the points of 0.9.* is the profile upgrader, it is
worthwhile making certain that this sort of thing doesn't happen.

Also, IMHO, a SEGV is *always* a bug.

Comment 5

[Michael Thome]

In case anyone cares, here's a gdb backtrace of the crash I see:
(gdb) bt
#0  0x081563ab in nsReadingIterator<char>::advance(int) ()
#1  0x084cbfb9 in nsPRUint32Key::Clone() const ()
#2  0x084ce4ba in nsPRUint32Key::Clone() const ()
#3  0x084ce59c in nsPRUint32Key::Clone() const ()
#4  0x084ce59c in nsPRUint32Key::Clone() const ()
#5  0x084ce59c in nsPRUint32Key::Clone() const ()
#6  0x084cddc9 in nsPRUint32Key::Clone() const ()
#7  0x083f12b3 in nsPRUint32Key::Clone() const ()
#8  0x083f10cc in nsPRUint32Key::Clone() const ()
#9  0x083f2917 in nsPRUint32Key::Clone() const ()
#10 0x083fe196 in nsPRUint32Key::Clone() const ()
#11 0x083fe3c1 in nsPRUint32Key::Clone() const ()
#12 0x083f2142 in nsPRUint32Key::Clone() const ()
#13 0x0838f641 in nsPRUint32Key::Clone() const ()
#14 0x083e7221 in nsPRUint32Key::Clone() const ()
#15 0x083e6fc2 in nsPRUint32Key::Clone() const ()
#16 0x083e4e56 in nsPRUint32Key::Clone() const ()
#17 0x401067b9 in XPTC_InvokeByIndex () from /usr/local/firefox/libxpcom.so

Comment 6

[drichard]

This bug should be marked as Linux also, 0.9.0 and 0.9.1 do the same thing.  
Resetting profiles is not really a good option on a massive multi-user system.

Comment 7

[Adam Hauner]

TB95673E:
CompositeEnumeratorImpl::HasMoreElements 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/rdf/base/src/nsCompositeDataSource.cpp,
line 272]
nsRDFPropertyTestNode::FilterInstantiations 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/templates/src/nsRDFPropertyTestNode.cpp,
line 246]
TestNode::Propagate 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/templates/src/nsRuleNetwork.cpp,
line 1046]
TestNode::Propagate 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/templates/src/nsRuleNetwork.cpp,
line 1054]
TestNode::Propagate 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/templates/src/nsRuleNetwork.cpp,
line 1054]
TestNode::Propagate 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/templates/src/nsRuleNetwork.cpp,
line 1054]
RootNode::Propagate 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/templates/src/nsRuleNetwork.cpp,
line 761]
nsXULContentBuilder::CreateTemplateAndContainerContents 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/templates/src/nsXULContentBuilder.cpp,
line 1150]
nsXULContentBuilder::RebuildAll 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/templates/src/nsXULContentBuilder.cpp,
line 1971]
nsXULTemplateBuilder::Rebuild 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/templates/src/nsXULTemplateBuilder.cpp,
line 238]
nsXULDocument::AttributeChanged 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 1140]
nsXULElement::SetAttrAndNotify 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2225]
nsXULElement::SetAttr 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2148]
nsXULElement::SetAttribute 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 1022]
XPTC_InvokeByIndex 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2027]
XPC_WN_CallMethod 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 941]
js_Interpret 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 2973]
js_Invoke 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 958]
js_Interpret 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 2973]
js_Invoke 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 958]
js_InternalInvoke 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1035]
JS_CallFunctionValue 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c,
line 3607]
nsJSContext::CallEventHandler 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1297]
nsJSEventListener::HandleEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsEventListenerManager::HandleEventSubType 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1434]
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1512]
GlobalWindowImpl::HandleDOMEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 892]
DocumentViewerImpl::LoadComplete 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp,
line 913]
nsDocShell::EndPageLoad 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 4330]
nsWebShell::EndPageLoad 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/docshell/base/nsWebShell.cpp,
line 805]
nsDocShell::OnStateChange 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/docshell/base/nsDocShell.cpp,
line 4264]
nsDocLoaderImpl::FireOnStateChange 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp,
line 1232]
nsDocLoaderImpl::doStopDocumentLoad 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp,
line 867]
nsDocLoaderImpl::OnStopRequest 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/uriloader/base/nsDocLoader.cpp,
line 695]
nsLoadGroup::RemoveRequest 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/netwerk/base/src/nsLoadGroup.cpp,
line 695]
nsCachedChromeChannel::HandleStopLoadEvent 
[c:/builds/tinderbox/firefox_branch/WINNT_5.0_Clobber/mozilla/chrome/src/nsChromeProtocolHandler.cpp,
line 485]
ntdll.dll + 0x30c24 (0x778b0c24)

Comment 8

[Jay Patel [:jay]]

This is a topcrasher with Firefox 0.9.1.  We already have a stack, so here are a
few user comments to help us reproduce:

     (203546)	Comments: Had one web page open  did Options -> Download and
crash occurred. Please ignore previous description (Java app closed) - there was
no Java app running this time.
     (205371)	Comments: When opening Tools->Options it crashed.
     (206636)	Comments: checking options
     (204240)	Comments: Clicked on tools  options  downloads  then it crashed
     (193411)	Comments: Tools -> Options -> Download
     (203531)	Comments: Was closing an *EXTERNAL* Java application (.jar file)
and FireFox crashed.
     (201492)	Comments: setting preferences in the options page
     (193777)	Comments: I tried to view the downloads menu  
     (192389)	Comments: clicked on the back button
     (189847)	Comments: changing profile  switching to next category
     (197599)	Comments: tried to bookmark a page after new installation of
firefox 0.9.1
     (193127)	Comments: Start FileFox  Bookmarks -> Bookmark this page
     (193122)	Comments: Start FileFox  Bookmarks -> Bookmark this page

Comment 9

[chris hofmann]

blake, are we going to be able to get this for RC1?

Comment 10

[Blake Ross]

Just checked in a patch that should fix this. I'll keep my eye on future
talkback reports.

Comment 11

[chris hofmann]

hooray!  my life watching webmaster mail just got a lot better. ;-)  thanks

Comment 12

[drichard]

ping:  This is still broken on the Linux 7/28 Trunk nightly.  Can anyone confirm
that this is fixed.  Still crashes for me immediately when I click on the
"Download" option as it did before.

Comment 13

[Mike Connor [:mconnor]]

can you provide a talkback ID for this crash so we can determine if its the same
thing?

Comment 14

[drichard]

When it crashes I get this on the command line:

X Error of failed request:  BadFont (invalid Font parameter)
  Major opcode of failed request:  55 (X_CreateGC)
  Resource id in failed request:  0x680002e
  Serial number of failed request:  421
  Current serial number in output stream:  441

I'm also going to attach the output of the Talkback wizard.  It submitted the
information but didn't give me a number to reference.

Comment 15

[drichard]

Attachment: Talkback Crashed Output

Generated with Talkback on this crash.

Comment 16

[drichard]

Sorry to all of the CC's on this list.  I need to generate a new debug log,
doing that now.  In looking at the talkback log, I can see that trunk Firefox
running as 'root' stole my session running in my account name on the same
DISPLAY which is an older build. Wow, it really shouldn't do that if the two
user names are different.   Trunk build from yesterday still fails attempting to
get a  BT.

Comment 17

[drichard]

Attachment: Crash of Trunk Firefox, after clicking on Download button

Comment 18

[Jay Patel [:jay]]

I found drichard's incident id for the first crash he mentioned (which was with
the original Firefox 0.9):
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=438679

I couldn't dig up the second crash mentioned though (the one with a recent
FirefoxTrunk build).

Blake: Did this fix get on both the aviary branch and trunk?

Comment 19

[drichard]

I didn't submit a second Talkback and instead attached it here.  It wasn't
generating numbers that I could reference for you so I didn't wanted to clutter
Bugzilla with more data.  I can easily do so if it contains more information
than the attached .txt file.

Comment 20

[Jay Patel [:jay]]

drichard: Please try crashing again with the FirefoxTrunk build and submit a
Talkback incident (make sure to include your email address so we can look it
up).  Or you can just run talkback in /mozilla/components/talkback and post the
id displayed in the Talkback client window.

Comment 21

[drichard]

Sent, put Bugzilla Number in the description.

Comment 22

[drichard]

Same crash happened on Linux with 0.9.3, submitted a TalkBack report and will
match my email address.

Comment 23

[Jay Patel [:jay]]

Before I reopen this, I wanted to make sure this crash is reproducible on the
Firefox10 Aviary branch.

drichard:  This crash will still be in Firefox 0.9.3 because that is based off
the old 0.9.1/2 branch.  The fix here has been checked into the latest Aviary
branch (labeled XXXX-XX-XX-XX-0.9 in the nightlies)...so if you crashed with one
of those builds, then we might need to reopen this.

Here are your incidents: 
490857 CompositeEnumeratorImpl::HasMoreElements() 03c01c3b 	2004-08-05
10:35:47.0 	MozillaOrgFirefox10LinuxIntel2004080312 	Linux 2.4.18-14bigmem 
[e-mail] 	
Clicked on "Download" button to configure my download settings and immediately
crashed. 	U3BFC14C3-F06B-43B6-AE7E8D7F-8E865019 	207.22.154.205

441904 	CompositeEnumeratorImpl::HasMoreElements() 77c44a47 	2004-07-29
13:55:11.0 	MozillaOrgFirefoxTrunkLinuxIntel2004072810 	Linux 2.4.18-14bigmem 
[e-mail] 	
Clicked on Download Button, per bug # 247054 
U3BFC14C3-F06B-43B6-AE7E8D7F-8E865019 	207.22.154.205

438679  CompositeEnumeratorImpl::HasMoreElements() b8bb1fb0 	2004-07-29
06:07:26.0 	MozillaOrgFirefox10LinuxIntel2004061500 	Linux 2.4.18-14bigmem 
[e-mail] 	Clicked on "Download" button
In preferences, clicked on the "download" button and immediate crash

From Talkback data, it is difficult to tell whether a crash happened on the
latest Aviary branch or 0.9.x minor releases (because they both share the
Firefox10 product name and we have been building both on the same days).

Please try crashing again and make sure you have a recent nightly of the Aviary
branch (in Help->About Mozilla Firefox you should see a user-agent string like
this: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040804
Firefox/0.9.1+). Please include that string in your Talkback reports comment
field so we can verify.  Thanks!

Comment 24

[drichard]

OK, brought down latest snapshot and still crashed in the same spot. Submitted
Talkback.  Talkback reveals version number to be 20040805 which is correct.

Crash was on Linux server, to remote display on thin client. 

Comment 25

[Jay Patel [:jay]]

drichard's latest id: 496908 - It's on the FirefoxTrunk, so we need to find out
if this fix made it to the Trunk.  

Blake?  I don't know where your patch landed...please let us know where this was
fixed.

Reopening until we can verify this was fixed.

Comment 26

[Blake Ross]

Fixed on branch only, I haven't checked this into the trunk yet.

Comment 27

[drichard]

Removing myself, we couldn't wait for this to get fixed any longer and I ended
up deleting everyones $HOME/.mozilla/firefox directory to reset everything back
to defaults which is the work around. :(

Comment 28

[Jay Patel [:jay]]

Blake:  Did this make it onto the Trunk?  If so, we can mark this fixed...if
not, any idea on when you'll be patching up the Trunk?  Or has this crash been
fixed by another change on the Trunk? I don't see any crashes like this in
recent Talkback data for either the Trunk or Aviary branch.

Comment 29

[Michael Thome]

FWIW, I haven't seen this on 1.0PR or 1.0RC1 (or various nightlies).

Comment 30

[Worcester12345]

(In reply to comment #29)
> FWIW, I haven't seen this on 1.0PR or 1.0RC1 (or various nightlies).

It was fixed in Aviary branch on   	2004-08-09

Comment 31

[Jay Patel [:jay]]

r.fixed based on last comment and latest Talkback data for Firefox 1.0, no more
crashes.

Comment 32

[Jay Patel [:jay]]

I don't see any crashes in the FirefoxTrunk either.  If anyone is able to
reproduce this or thinks we still need to patch the Trunk, please reopen.

Comment 33

[Mike Connor [:mconnor]]

sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs,
filter on "beltznerLovesGoats" to get rid of this mass change