crash on exit during load

RESOLVED FIXED in mozilla0.9

Status

()

Core
Document Navigation
P3
critical
RESOLVED FIXED
18 years ago
17 years ago

People

(Reporter: buster, Assigned: Radha on family leave (not reading bugmail))

Tracking

({crash})

Trunk
mozilla0.9
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-][PDTP3], URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
I have an optimized build with symbols turned on, source pulled approx 5/25.
In mozilla, load test case
Click around (sorry, there's lots of link and I was on the site for a while 
trying to reproduce another crash.)
While a document is loading into a frame, exit the browser.

I got this crash because there was a null mDocShell.  Maybe this method just 
needs a null check?  Or maybe some shutdown code needs to call RevokeEvents on 
the event queue?

nsDSURIContentListener::DoContent() line 97 + 5 bytes
nsDocumentOpenInfo::DispatchContent() line 350
nsDocumentOpenInfo::OnStartRequest() line 196 + 14 bytes
nsHTTPFinalListener::OnStartRequest() line 1145 + 24 bytes
nsHTTPCacheListener::OnStartRequest() line 146 + 16 bytes
nsDiskCacheRecordChannel::OnStartRequest() line 647
nsOnStartRequestEvent::HandleEvent() line 212 + 12 bytes
nsStreamListenerEvent::HandlePLEvent() line 106
PL_HandleEvent() line 576
PL_ProcessPendingEvents() line 520 + 6 bytes
_md_EventReceiverProc() line 1030 + 10 bytes


NS_IMETHODIMP nsDSURIContentListener::DoContent(const char* aContentType, 
   nsURILoadCommand aCommand, const char* aWindowTarget, 
   nsIChannel* aOpenedChannel, nsIStreamListener** aContentHandler,
   PRBool* aAbortProcess)
{
   NS_ENSURE_ARG_POINTER(aContentHandler);
   if(aAbortProcess)
      *aAbortProcess = PR_FALSE;

   // determine if the channel has just been retargeted to us...
   nsLoadFlags loadAttribs = 0;
   aOpenedChannel->GetLoadAttributes(&loadAttribs);

   if(loadAttribs & nsIChannel::LOAD_RETARGETED_DOCUMENT_URI)
      mDocShell->StopCurrentLoads();

   mDocShell->OnLoadingSite(aOpenedChannel);

   NS_ENSURE_SUCCESS(mDocShell->CreateContentViewer(aContentType, 
      aOpenedChannel, aContentHandler), NS_ERROR_FAILURE);

   if(loadAttribs & nsIChannel::LOAD_RETARGETED_DOCUMENT_URI)
      mDocShell->SetFocus();

   return NS_OK;
}

Comment 1

18 years ago
Adding crash to keyword field.
Keywords: crash

Comment 2

18 years ago
Can you reproduce the problem with a recent build?

Updated

18 years ago
Keywords: embed

Updated

18 years ago
Keywords: nsbeta3

Comment 3

18 years ago
QA: can you reproduce?
Whiteboard: [nsbeta3+]

Updated

18 years ago
Target Milestone: --- → M18

Updated

18 years ago
Priority: P3 → P2

Comment 4

17 years ago
PDT thinks this is a P3
Priority: P2 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP3]
(Reporter)

Comment 5

17 years ago
Jud: no one in qa will see your request for help to reproduce, because no one in 
qa is listening to this bug.  You or Rick should probably find someone in qa to 
help reproduce.  If I get a minute, I'll try to get a stack trace as well.

Comment 6

17 years ago
minusing per PDT rules.
Whiteboard: [nsbeta3+][PDTP3] → [nsbeta3-][PDTP3]

Updated

17 years ago
Target Milestone: M18 → ---

Comment 7

17 years ago
This crash is reproducable with 2001030205/Win2k.

Talkback ID: TB27290406G

Comment 8

17 years ago
from talkback:

0x00720074 
necko.dll + 0xb9b4 (0x606bb9b4) 
necko.dll + 0x37060 (0x606e7060) 
necko.dll + 0x55b6 (0x606b55b6) 
necko.dll + 0x2755 (0x606b2755) 
xpcom.dll + 0x3194b (0x60d7194b) 
xpcom.dll + 0x318b9 (0x60d718b9) 
xpcom.dll + 0xd79c (0x60d4d79c) 

Comment 9

17 years ago
pulling embed keyword.
Keywords: embed

Comment 10

17 years ago
-> mozilla0.9
Target Milestone: --- → mozilla0.9

Comment 11

17 years ago
I can't repro this as altoids doesn't even let our browser in (flash related 
plugin bugs it looks like).
Taking from rpotts as he is swamped for 0.9
Assignee: rpotts → radha
Right now going to the above website redirects to  
http://www.altoids.com/netscape6.htm, which just asks you to use previous 
versions due to compatibility issues. Can someone give another  test case?
Created attachment 30426 [details] [diff] [review]
Patch to nsDSURIListener.cpp
I have attached a patch which makes sure the pointers are valid before we access 
them. Not sure if that fixes the problem, but it definitely does the right 
thing. 

Updated

17 years ago
Blocks: 75664
That method now looks pretty safe. r=ccarlen

Updated

17 years ago
No longer blocks: 75664

Comment 17

17 years ago
r=valeski.

Comment 18

17 years ago
sr=rpotts

looks safe to me :-)
fix checked in to do null pointer check in nsDSUriListener::DoContent()
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.