Closed Bug 41065 Opened 20 years ago Closed 20 years ago

crash on exit during load

Categories

(Core :: DOM: Navigation, defect, P3)

x86
Windows NT
defect

Tracking

()

RESOLVED FIXED
mozilla0.9

People

(Reporter: buster, Assigned: radha)

References

()

Details

(Keywords: crash, Whiteboard: [nsbeta3-][PDTP3])

Attachments

(1 file)

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;
}
Adding crash to keyword field.
Keywords: crash
Can you reproduce the problem with a recent build?
Keywords: embed
Keywords: nsbeta3
QA: can you reproduce?
Whiteboard: [nsbeta3+]
Target Milestone: --- → M18
Priority: P3 → P2
PDT thinks this is a P3
Priority: P2 → P3
Whiteboard: [nsbeta3+] → [nsbeta3+][PDTP3]
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.
minusing per PDT rules.
Whiteboard: [nsbeta3+][PDTP3] → [nsbeta3-][PDTP3]
Target Milestone: M18 → ---
This crash is reproducable with 2001030205/Win2k.

Talkback ID: TB27290406G
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) 
pulling embed keyword.
Keywords: embed
-> mozilla0.9
Target Milestone: --- → mozilla0.9
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?
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. 
Blocks: 75664
That method now looks pretty safe. r=ccarlen
No longer blocks: 75664
r=valeski.
sr=rpotts

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