Closed Bug 40116 Opened 24 years ago Closed 24 years ago

Crash in nsDSURIContentListener::DoContent loading this URL

Categories

(Core :: Networking, defect, P1)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jprice, Assigned: mscott)

References

(
URL
)

Details

(Keywords: crash, top100, Whiteboard: [nsbeta2+][dogfood-])

Attachments

(1 file)

proposed fix....
2.80 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; I; Linux 2.2.12-20 i686)
BuildID:    2000052120

Whenever you go to this page, the browser crashes.  It looks like it's in the
process of rendering the page, then the page top (navigation aids, and
advertisments) start to look odd, then the whole shebang crashes.  (other
mozilla windows you have open crash too.  The whole process ends)

Reproducible: Always
Steps to Reproduce:
1.  Load url.
2.  process dies.


Actual Results:  The entire process dies.  All windows spawned in that session
come down with it.

Expected Results:  Finish rendering the page.

I seem to be able to re-produce this at will.  If you need me to, I can mail out
the full console output, however it doesn't SEEM to be anything pertinant...
just a bunch of "WEBSHELL+ = #" where # ranges from 11-15, and a LOT of "Warning
- table cell content max element height 285 greater than desired height 270"
errors (or errors that differ in the numbers only).

This is a redhat linux 6.1, slightly updated.  celeron 300a, 128 megs

If I can be of further help, please let me know at jprice@gatech.edu
Also confirmed with build 2000052120 on Win2K
Status: UNCONFIRMED → NEW
Ever confirmed: true
Stack trace on PC/Linux, built from the 5/21 sources:

#0  0x4172b330 in nsDSURIContentListener::DoContent ()
   from libdocshell.so
#1  0x406fc726 in nsDocumentOpenInfo::DispatchContent ()
   from components/liburiloader.so
#2  0x406fc173 in nsDocumentOpenInfo::OnStartRequest ()
   from components/liburiloader.so
#3  0x4069cd3a in nsHTTPFinalListener::OnStartRequest ()
   from components/libnecko.so
#4  0x4069ade1 in nsHTTPCacheListener::OnStartRequest ()
   from components/libnecko.so
#5  0x40684034 in nsDiskCacheRecordChannel::OnStartRequest ()
   from components/libnecko.so
#6  0x40658bb9 in nsOnStartRequestEvent::HandleEvent ()
   from components/libnecko.so
#7  0x406586b5 in nsStreamListenerEvent::HandlePLEvent ()
   from components/libnecko.so
#8  0x400bb35f in PL_HandleEvent ()
   from libxpcom.so
#9  0x400bb286 in PL_ProcessPendingEvents ()
   from libxpcom.so
#10 0x400bc139 in nsEventQueueImpl::ProcessPendingEvents ()
   from libxpcom.so
#11 0x40a272bf in event_processor_callback ()
   from components/libwidget_gtk.so
#12 0x40a2702f in our_gdk_io_invoke ()
   from components/libwidget_gtk.so

Adding crash kw, adding new info to summary.
Keywords: crash
Summary: complete mozilla crash on loading this URL. → Crash in nsDSURIContentListener::DoContent loading this URL
 This may be a duplicate of bug #39897, which seems to have the same URL
and roughly the same stack backtrace (same routines called in the same
order, from what I can see).

 I suspect that this makes it an all-platform bug, especially given
bug #40261.

 I would like to nominate this bug as a dogfood /nsbeta2 issue, because
I'm also seeing this crash on http://news.bbc.co.uk/ when one hits Back
to come back out of a story to a main page. (I know this is a recent
regression, too; it used to work a couple of weeks ago.) With crashes
on at least two sites and if one prints on a third, and at least one
of the sites being a fairly major news provider, it seems reasonably
important to me. Mozilla.org may consider this non-dogfood and merely
nsbeta2 on the grounds that the BBC et al is not /that/ important.
Keywords: dogfood, nsbeta2
Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2.
Assignee: asadotzler → valeski
Component: Browser-General → Networking
QA Contact: jelwell → tever
Whiteboard: [nsbeta2+][dogfood-]
this is a dandy. At some point the docshell hands the URILoader it's
nsIURIContentListener (via GetInterface(), not QI), and the URI loader pumps
data to it and life is good. However, eventually that docshell is being
destroyed (which breaks the ref from the content listener class, to the
docshell, see
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsDocShell.cpp#1348 ), but
the content listener ref is still being maintained by the uri loader. Then, that
ref is used, again, by the uri loader to DoContent(), but the listener object's
(nsDSURIContentListener.cpp) mDocShell ptr is null and we try to access it.
Simply making that ptr a comptr won't cut it because we'd be stuck w/ a circular
reference. Something is broken in the design here. I think the uri loader is
hanging onto a content listener too long (ie. after the docshell has gone away).

Over to mscott.
Assignee: valeski → mscott
*** Bug 39897 has been marked as a duplicate of this bug. ***
*** Bug 40261 has been marked as a duplicate of this bug. ***
I have verified that the two bugs Chris mentioned really have the same stack
strace, and thus marked them dup of this one. Changing OS to All per bug 39897
(thanks to Chris for the hint), and adding some people from duped bugs to CC.
OS: Linux → All
*** Bug 39130 has been marked as a duplicate of this bug. ***
beta2+ = M16/m17.
Target Milestone: --- → M17
This stack trace also occurs when trying to print the http://www.espn.go.com/
to a file (this URL is mentioned in bug 38768).
Blocks: 38768
*** Bug 41462 has been marked as a duplicate of this bug. ***
accepting.
Status: NEW → ASSIGNED
Priority: P3 → P1
*** Bug 41904 has been marked as a duplicate of this bug. ***
*** Bug 42168 has been marked as a duplicate of this bug. ***
*** Bug 42252 has been marked as a duplicate of this bug. ***
*** Bug 42260 has been marked as a duplicate of this bug. ***
Here's a first look at a potential fix for this crash. It definetly fixes the
crash but is partially incomplete for two reasons:
1) When I load this page in 4.x, we get an etrade banner ad in the middle of the
page (this was the url that was causing the crash). In seamonkey with my fix to
prevent the crash, I never see the etrade banner ad.

2)The second problem is with the fact that I'm canceling and just falling out. I
need to cancel the uriload and then go through the web progress to broadcast the
fact that the url has been canceled. But I have another bug to track that =).
Attached patch proposed fix.... — — Splinter Review 

    
    

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

    
    

    
  
Adding top100 keyword (from bug 42564).
Keywords: top100

    
    

    
  
I've fixed the crash reported in this bug. However, for some reason layout isn't
layout the part we are trying to reload when we used to crash in docshell.

Marking fixed.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
today's mozilla builds

verified:
Linux 2000062608
NT 2000062609
Status: RESOLVED → VERIFIED

    
    

    
  
I'm seeing this bug again in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

http://www.washingtonpost.com/wp-dyn/articles/A61543-2004Mar15.html

If the link doesnt work, just try any Washington Post article from
http://news.google.com

Thanks!

    
    

    
  
Matthew, please report this as a new bug. I don't want to repoen this bug.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: