Closed Bug 472312 Opened 16 years ago Closed 16 years ago

Trying to open the full-size image on Google images crashed the browser [@ nsSubDocumentFrame::ShowDocShell()]


(Core :: Layout: Images, Video, and HTML Frames, defect, P2)






(Reporter: whimboo, Assigned: smaug)




(Keywords: crash, fixed1.9.1, topcrash)

Crash Data


(3 files)

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090104 Shiretoko/3.1b3pre ID:20090104020455

I did a search on Google Images and tried to open one of the images directly in full-size by clicking the top link. For now I cannot supply a URL but will try to get the STR in some minutes.

crash report: bp-5337bcb0-0ce3-4282-aa72-579ff2090106

First 10 frames:

0  	XUL  	nsSubDocumentFrame::ShowDocShell  	layout/generic/nsFrameFrame.cpp:914
1 	XUL 	nsSubDocumentFrame::ShowViewer 	layout/generic/nsFrameFrame.cpp:327
2 	XUL 	nsSubDocumentFrame::Init 	layout/generic/nsFrameFrame.cpp:312
3 	XUL 	nsCSSFrameConstructor::InitAndRestoreFrame 	layout/base/nsCSSFrameConstructor.cpp:6782
4 	XUL 	nsCSSFrameConstructor::ConstructHTMLFrame 	layout/base/nsCSSFrameConstructor.cpp:5582
5 	XUL 	nsCSSFrameConstructor::ConstructFrameInternal 	layout/base/nsCSSFrameConstructor.cpp:7556
6 	XUL 	nsCSSFrameConstructor::ConstructFrame 	layout/base/nsCSSFrameConstructor.cpp:7428
7 	XUL 	nsCSSFrameConstructor::ContentAppended 	layout/base/nsCSSFrameConstructor.cpp:8612
8 	XUL 	PresShell::ContentAppended 	layout/base/nsPresShell.cpp:4720
9 	XUL 	nsNodeUtils::ContentAppended 	content/base/src/nsNodeUtils.cpp:119
10 	XUL 	nsContentSink::NotifyAppend 	content/base/src/nsContentSink.cpp:1332
The crash happened with the following STR but I'm not able to reproduce ATM.

1. Open the given URL
2. Click onto the "See full size image" link while page is loading
As what I can see now, this is topcrasher #1 for Firefox 3.1b3pre on all platforms/OS. There is no crash with this top frame listed for 3.1b2.

The stack on Windows is a bit different:


0  	xul.dll  	nsSubDocumentFrame::ShowDocShell  	layout/generic/nsFrameFrame.cpp:995
1 	xul.dll 	nsStyleContext::GetStyleDisplay 	layout/style/nsStyleStructList.h:95
2 	xul.dll 	nsSubDocumentFrame::ShowViewer 	layout/generic/nsFrameFrame.cpp:327
3 	xul.dll 	nsSubDocumentFrame::Init 	layout/generic/nsFrameFrame.cpp:312
Keywords: topcrash
OS: Mac OS X → All
Hardware: x86 → All
The steps in comment 1 work for me on mac...

The stack's frame 0 or frame 1 is pretty clearly broken.  I suspect it's the frame 1 that's broken...  The line number in the Windows stack is totally bogus, but the Mac one is the call on the docshell inside ShowDocShell.

The only way to get back a null here is to have no owner content in the frameloader.  Not sure whether that can happen.  smaug?
Comments by users:

* wandering around my amazon shopping cart.
* two tabs open. one on facebook with an ajax post message type popup and the other at the guardian. Crash happened after I switched to the guardian tab and started loading the page.
*I was adding a book to my wishlist on This is the third time this has happened in 5 min with 2 seperate books.
* Clicking on an image in amazon.

* Had been using Facebook, and I wrote a note on a friend's wall and Shiretoko crashed
* Clicked "back" on an overly complex ebay page.
* browsing ebay (:

Seems like mostly happen on Amazon and Ebay. I'm also not able to reproduce my given steps from comment 1.
Chris, do you have access to some of the urls given by the crash reports? It would make the life easier to find possible crashing sites.
Assignee: nobody → Olli.Pettay
Version: 1.9.1 Branch → Trunk
Haven't managed to reproduce (tested OSX and Linux).
But anyway, looking what could cause this.
Depends on: 472471
henrik,  hoping to have a list of urls soon.  I'll sanitize and post.
Thanks Chris! Perhaps you should also have a look at bug 472471. I've already filed a separate bug on the URL retrieval.
I looked through the crash data on my laptop and found that I crashed in this stack on 12/27 ->

I recall I was looking at on item on Amazon, clicked the image link, and then I crashed. Since then I have not been able to reproduce the crash.
here is a prelimiary list of urls WHERE
p.product = 'Firefox' AND p.version = '3.2a1pre'
AND '2008-12-28' <= day AND day <= '2009-01-05'
AND sig.signature = 'nsSubDocumentFrame::ShowDocShell()' 

I don't seem to reproduce crashes on any of these using Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090105 Shiretoko/3.1b3pre Ubiquity/0.1.4
Depends on: 472260
Based on crash reports it is bug 431082 which might have caused this.
Attached patch a patchSplinter Review
Boris, I'd like to try this patch. Destroy docshell when unbinding
element or destroying frameloader.
Doesn't regress bug 431082.
Attachment #356013 - Flags: superreview?(bzbarsky)
Attachment #356013 - Flags: review?(bzbarsky)
The patch is backing out part of bug 431082.
And passes mochitest etc.
Hrm.  We have no idea why that causes this problem do we?  :(

Could we add an assert for cases when we hit this code or something?  And see why it happens?
Comment on attachment 356013 [details] [diff] [review]
a patch

Please leave a comment that Destroy() is NOT to be called here, with pointer to this bug.  And add that NS_ERROR, please.
Attachment #356013 - Flags: superreview?(bzbarsky)
Attachment #356013 - Flags: superreview+
Attachment #356013 - Flags: review?(bzbarsky)
Attachment #356013 - Flags: review+
Attached patch +NS_WARNINGSplinter Review
I decided to use NS_WARNING because bug 431082 triggers it.
NS_WARNING won't help much with catching it in other cases (e.g. in other tests Jesse cooks up)....
I've got a longer list of URLs now (~1600).  Is it content from the sites on
these pages that seems to be causing the crash, or some interaction between
windows, or combination, or some other reason entirely?   Here is a rough
summary of sites that had more that 10 instances of crashes for this bug.  We
could drill down more on the specific page content for the sites below, but I'm
guessing that is not needed now.

crash instances - site

Attached patch +NS_ERROR thenSplinter Review
Attachment #356021 - Attachment is obsolete: true
*Not* marking fixed before results from crash-stats.m.c
So all the leak test boxes are red because they're hitting this assertion... I'm going to back out the patch unless you beat me to it.
Er, actually, only the Linux one; the Windows red was something else.
It actually did eventually show up on Mac and Windows as well.
I change NS_ERROR to NS_WARNING for now. I really need to know if the crash is
fixed in the nightlies.
Blocks: 431082
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Attachment #356021 - Attachment is obsolete: false
Attachment #356021 - Flags: approval1.9.1?
Indeed. Build 20090108040418 is the latest build on trunk with the crash reported.

Smaug, I don't think that we need another patch for trunk and can mark this bug as fixed?
Comment on attachment 356021 [details] [diff] [review]

Removing approval flag: this is a blocker, and so it doesn't need explicit a+
Keywords: fixed1.9.1
There are no more crash reports for builds later than Jan 8th. I believe we can safely mark this bug as fixed.
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2a1
Would still be nice to get a testcase somehow so we can add it to the crashtests.
Keywords: testcase-wanted
Is just NS_WARNING enough here? Comment 19 suggests otherwise. Locally I had worked around this by bailing in ShowDocShell if we got a nsnull docShell for an NS_OK return value (should we add an assertion there that we expect docShell never to be nsnull there? Or is crashing sufficient? ;-))
Crash Signature: [@ nsSubDocumentFrame::ShowDocShell()]
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
See Also: → 1679478
You need to log in before you can comment on or make changes to this bug.