144887 - Trunk crash [@ nsDSURIContentListener::OnStartURIOpen]

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Jay Patel [:jay]]

There are quite a few of these crashes happening on the MozillaTrunk on Linux
and Windows.  It's been a consistent crash for a while now I think.  Here is the
latest from Talkback:

nsDSURIContentListener::OnStartURIOpen   34 
BBID range: 5938207 - 6291077
Min/Max Seconds since last crash: 71 - 88186
Min/Max Runtime: 326 - 161808
Crash data range: 2002-05-04 to 2002-05-14
Build ID range: 2002050407 to 2002051409
Keyword List : 
Stack Trace: 

	 nsDSURIContentListener::OnStartURIOpen
[nsDSURIContentListener.cpp  line 76]
	 nsDSURIContentListener::OnStartURIOpen
[nsDSURIContentListener.cpp  line 76]
	 nsDSURIContentListener::OnStartURIOpen
[nsDSURIContentListener.cpp  line 76]
	 nsURILoader::OpenURIVia
[nsURILoader.cpp  line 524]
	 nsURILoader::OpenURI
[nsURILoader.cpp  line 499]
	 nsDocShell::DoChannelLoad
[nsDocShell.cpp  line 5155]
	 nsDocShell::DoURILoad
[nsDocShell.cpp  line 4934]
	 nsDocShell::InternalLoad
[nsDocShell.cpp  line 4723]
	 nsDocShell::LoadURI
[nsDocShell.cpp  line 665]
	 LocationImpl::SetHrefWithBase
[nsLocation.cpp  line 556]
	 LocationImpl::SetHrefWithContext
[nsLocation.cpp  line 489]
	 LocationImpl::SetHref
[nsLocation.cpp  line 458]
	 nsDocumentSH::SetProperty
[nsDOMClassInfo.cpp  line 4480]
	 XPC_WN_Helper_SetProperty
[xpcwrappednativejsops.cpp  line 793]
	 js_SetProperty
[jsobj.c  line 2680]
	 js_Interpret
[jsinterp.c  line 2586]
	 js_Execute
[jsinterp.c  line 970]
	 JS_EvaluateUCScriptForPrincipals
[jsapi.c  line 3377]
	 nsJSContext::EvaluateString
[nsJSEnvironment.cpp  line 703]
	 GlobalWindowImpl::RunTimeout
[nsGlobalWindow.cpp  line 4481]
	 GlobalWindowImpl::TimerCallback
[nsGlobalWindow.cpp  line 4846]
	 nsTimerImpl::Fire
[nsTimerImpl.cpp  line 345]
	 nsAppShell::Run
[nsAppShell.cpp  line 134]
	 nsAppShell::Run
[nsAppShell.cpp  line 134]
	 nsAppShellService::Run
[nsAppShellService.cpp  line 451]
	 main1
[nsAppRunner.cpp  line 1472]
	 main
[nsAppRunner.cpp  line 1808]
	 WinMain
[nsAppRunner.cpp  line 1826]
	 WinMainCRTStartup()
	 KERNEL32.DLL + 0xd326 (0x77e8d326)
 
 	Source File : nsDSURIContentListener.cpp line : 76
     (6291077)	URL:
http://www.games-fusion.net/cgi-bin/potd/sp.pl?src=http://www.games-fusion.net/images/fp7(3).JPG
     (6236472)	Comments: Mozilla was running in the background sitting at http://www.google.com
     (6236243)	URL:
http://www.games-fusion.net/cgi-bin/potd/sp.pl?src=http://www.games-fusion.net/images/fp7(3).JPG
     (6206964)	URL: www.met.hu
     (6166279)	URL: www.universalthread.com
     (6166279)	Comments: reading
     (6113666)	Comments: i was in another window and it just died probably while loading
some page
     (6111766)	URL: www.met.hu
     (6111766)	Comments: simple browsing  just read an article....
     (5946709)	URL: www.twmacinta.com/tricks/frames-split.html

Comment 1

[Jay Patel [:jay]]

Adding crash keywords and qawanted to see if we can get this reproduced.

Here is the code around the crash:
 70 NS_IMETHODIMP
 71 nsDSURIContentListener::OnStartURIOpen(nsIURI* aURI, PRBool* aAbortOpen)
 72 {
 73     if(mParentContentListener)
 74         return mParentContentListener->OnStartURIOpen(aURI, aAbortOpen);
 75 
 76     return NS_OK;
 77 }

Talkback is reporting line 76, but I'm guessing we're crashing on line 74...we
already check for mParentContentListener, but would it be crashing if
mParentContentListener was somehow NULL?

Here are the parameter values:

nsDSURIContentListener::OnStartURIOpen        
this = 0x03428a20           
(*this) = Data not available        
aURI = 0x032c5cf0           
(*aURI) = Data not available        
aAbortOpen = 0x0012f524           
(*aAbortOpen) = 0 (0x00000000) 

Comment 2

[greer]

My understanding is that the "[e-mail]" alias isn't
applicable right now. Reassigning to Darin to take a look at this one. (Darin,
feel free to unassign yourself if that's no good.)

Comment 3

[Jay Patel [:jay]]

It looks like this wasn't reassigned, doing so now to get some traction on this bug.

Comment 4

[Darin Fisher]

-> docshell

Comment 5

[Jay Patel [:jay]]

reassigning this to default docshell owners...darin, that's what you where
trying to do right?

Comment 6

[Darin Fisher]

jpatel: yes, thank you.

Comment 7

[Jonathan Ziegler]

Page loads. Get message:
"You are trying to view a picture on the Games Fusion-Server from another site.
We do not want other sites to steal our bandwidth, so if you want to help us
please send a mail to [e-mail] and tell us the URL of the site
you came from. Thanks!"

On one machine, it loads the image, not the message above. No crash.
Netscape 7.0 Preview Release 1; Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0)
Gecko/20020605 Netscape/7.0b1

Comment 8

[greer]

Attachment: Stack from my latest crash

I've been able to reproduce this crash twice on today's Trunk build.
1. Go to www.interland.com
2. Click on "Partner Enrollment" under the "Partner Programs" heading (lower
right). 
- The throbber shows that the page briefly loads something in the background
and that seems to be the cause of the crash.
3. If a crash does not occur entering the site, try clicking back.

Comment 9

[greer]

qawanted -> testcase
topcrash -> topcrash+

Comment 10

[Shiva Thirumazhusai]

nominating for nsbeta1

Comment 11

[Adam Lock]

That page has some kind of timer constantly refreshing the content. Perhaps URI
loading from the old content is arriving while the old content is being pulled
down. Trying to isolate what might be causing the page to reload so often.

Comment 12

[Adam Lock]

The page has this piece of wackiness buried in some external JS:

document.write('<iframe name="elqIntFra" style="visibility:hidden"
src="/elqNow/elqIFJS.htm?pps=30&siteID=' + elqSiteID + '&wstat=0&ref=' +
elqReplace(elqReplace(location.href,'&','%26'),'#','%23') + '" width=1 height=1
frameborder=0 border=0 NORESIZE SCROLLING="no"><\/iframe>');}

So the page is generating a hidden IFRAME which (after deciphering the js) loads
a frameset containing two blank frames and even more conditional js which
refreshes the page every second.

It is possible that the hidden frame and the content constantly refreshing is
causing odd behaviour in the URI content listener, e.g. listening to content
while the old content is being torn down.

Comment 13

[Adam Lock]

Attachment: Patch

This patch changes the content listener implementation to use proper weak
references. This will hopefully fix the problem. I have been unable to
reproduce the crash itself (before or after the patch). If someone can get it
to happen regularly, please try the patch out and report back.

Embedders registering their own content listeners that do not implement
nsISupportsWeakReference are still supported for API compatibility, but it will
assert at them in debug mode.

Comment 14

[Adam Lock]

Can I have a review for the patch please? 

I am unable to reproduce the original issue at all, so my hope is this patch to
use weak references will fix it. 

Comment 15

[Alec Flett]

Comment on attachment 90104 [details] [diff] [review]
Patch

is there any chance we can find out who is storing non-weak-ref-capable
listeners and just fix them? 

then we could just start enforcing that people use weak refs and not have the
added bloat of supporting both options.

Comment 16

[Adam Lock]

I believe the crash is occuring in Mozilla because a parent docshell is no
longer there when some content arrives. I hope by changing the URI listener to
support weak refs (and docshell to be a weak ref object) that I can prevent this
from happening. As I mentioned, I have no idea for sure how to replicate the
issue since none of the steps to reproduce do for me. So I'm guessing and hoping
this will work.

The reason I still support the old style is because nsIURIContentListener and
places which expose it to embedders such as nsIWebBrowser are frozen. We can't
change the semantics of these interfaces by insisting that listeners must now be
proper weak ref objects.

Comment 17

[Alec Flett]

Comment on attachment 90104 [details] [diff] [review]
Patch

ah ok, I didn't realize they were frozen. sr=alecf

Comment 18

[Radha on family leave (not reading bugmail)]

Comment on attachment 90104 [details] [diff] [review]
Patch

r= radha for attachment 90104 [details] [diff] [review]

Comment 19

[Adam Lock]

Fix is checked in. We'll have to monitor talkbacks to see if the problem resurfaces.

Comment 20

[greer]

*** Bug 156952 has been marked as a duplicate of this bug. ***

Comment 21

[Jay Patel [:jay]]

This crash last appeared with MozillaTrunk builds from 7/7 so marking verified.
 Please reopen if this stack signature shows up again in Talkback data or if
anyone is able to reproduce.