71498 - M092 Trunk crash [@ Distance - nsScanner::RewindToMark] Unknown Content Type transfers

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Jay Patel [:jay]]

Talkback is reporting a crash for Mozilla 0.8 (M08) on Linux with the same stack 
trace as the one posted on 2/27 in bug 70172 (a mail/news bug).  Wasn't sure it 
was the same crash, so logging new bug. 

Here is the latest stack trace from talkback and some talkback entries with user 
comment/urls:

Distance() 
nsScanner::RewindToMark() 
nsParser::Tokenize() 
nsParser::ResumeParse() 
nsParser::OnDataAvailable() 
nsDocumentOpenInfo::OnDataAvailable() 
nsUnknownDecoder::FireListenerNotifications() 
nsUnknownDecoder::OnStopRequest() 
nsDocumentOpenInfo::OnStopRequest() 
nsHTTPFinalListener::OnStopRequest() 
nsHTTPChannel::ResponseCompleted() 
nsHTTPServerListener::OnStopRequest() 
nsOnStopRequestEvent::HandleEvent() 
nsStreamObserverEvent::HandlePLEvent() 
PL_HandleEvent() 
PL_ProcessPendingEvents() 
nsEventQueueImpl::ProcessPendingEvents() 
event_processor_callback() 
our_gdk_io_invoke() 
libglib-1.2.so.0 + 0xebf0 (0x40654bf0) 
libglib-1.2.so.0 + 0x102b9 (0x406562b9) 
libglib-1.2.so.0 + 0x108c3 (0x406568c3) 
libglib-1.2.so.0 + 0x10a5c (0x40656a5c) 
libgtk-1.2.so.0 + 0x8e457 (0x40578457) 
nsAppShell::Run() 
nsAppShellService::Run() 
main1() 
main() 
libc.so.6 + 0x1cf5c (0x4024af5c) 

Distance() 4678fc77
         line 
        Build: 2001021504 CrashDate: 2001-02-23 UptimeMinutes: 268  Total: 268 
        OS: Linux 2.2.16-22
        URL: 
        Comment: Clicking on a link to download a source RPM from rpmfind
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=26804770
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=26804770
     
Distance() 4afcb53e
         line 
        Build: 2001021504 CrashDate: 2001-02-27 UptimeMinutes: 333  Total: 419 
        OS: Linux 2.2.16-SMP
        URL: 
        Comment: open ftp server (sunsite)
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=26992618
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=26992618

Distance() 12d82955
         line 
        Build: 2001021504 CrashDate: 2001-02-27 UptimeMinutes: 152  Total: 152 
        OS: Linux 2.2.14-5.0
        URL: 
        Comment: downloading kernel rpm from redhat (ftp transaction)
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=27003025
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=27003025

Distance() 91848784
         line 
        Build: 2001021504 CrashDate: 2001-02-27 UptimeMinutes: 4216  Total: 6216 
        OS: Linux 2.4.1
        URL: ftp://ftp.uk.linux.org/pub/linux/linux2.2/ (or somewhere similar!)
        Comment: Attempting to ftp-transfer the 2.2.18 linux kernel 
(linux-2.2.18.tar.bz2)
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=27003141
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=27003141

Distance() 2bafcb0d
         line 
        Build: 2001021504 CrashDate: 2001-02-27 UptimeMinutes: 24  Total: 24 
        OS: Linux 2.2.14-5.0
        URL: ftp://ftp.redhat.com/cant_quite_remember_the_rest
        Comment: I pasted an URL into the URL box. Mozilla had failed on a few 
previous attempt to download via ftp
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=27006068
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=27006068

Distance() 3fbc10d3
         line 
        Build: 2001021504 CrashDate: 2001-03-03 UptimeMinutes: 19054  Total: 
19054 
        OS: Linux 2.2.16-22
        URL: was testing a servlet that does not yet provide a response object 
on localhost 
        Comment: was testing a servlet that does not yet provide a response 
object on localhost:8080with tomcat 3.21
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=27230221
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=27230221

Distance() 252e0a55
         line 
        Build: 2001021504 CrashDate: 2001-03-04 UptimeMinutes: 2139  Total: 2139 
        OS: Linux 2.2.16
        URL: http://web.syr.edu/~dbgrandi/delz/linux.htm
        Comment: clicked on this link w/in above document before page was fully 
loaded:ftp://ftp.rge.com/pub/linux/sunsite/docs/HOWTO/UPS-HOWTO
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=27264262
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=27264262

Distance() 5551e9b7
         line 
        Build: 2001021504 CrashDate: 2001-03-04 UptimeMinutes: 196  Total: 308 
        OS: Linux 2.4.2
        URL: www.enlightenment.org
        Comment: tried to access the ftp  link
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=27289152
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=27289152

Distance() 568630ef
         line 
        Build: 2001021504 CrashDate: 2001-03-05 UptimeMinutes: 4569  Total: 4569 
        OS: Linux 2.2.16-22
        URL: 
ftp://ftp.redhat.com/pub/redhat/redhat-7.0/i387/RedHat/RPMS/vim-enhanced-5.7-6.i
386.rpm
        Comment: Just clicked on link to download enhanced vim rpm
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=27322797
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=27322797

Comment 1

[Jay Patel [:jay]]

Adding crash, topcrash keywords, M08 and [@ Distance - nsScanner::RewindToMark] 
for tracking. 

Comment 2

[Doug Turner (:dougt)]

Adjusting summary.  

Basically, what the traced are telling me is that the nsUnknownDecoder is 
feeding data to the parser which it does not like.  This is not a FTP specific 
problem as 27230221 has a stack that looks like:

Incident ID 27230221 
Distance() 
nsScanner::RewindToMark() 
nsParser::Tokenize() 
nsParser::ResumeParse() 
nsParser::OnDataAvailable() 
nsDocumentOpenInfo::OnDataAvailable() 
nsUnknownDecoder::FireListenerNotifications() 
nsUnknownDecoder::OnStopRequest() 
nsDocumentOpenInfo::OnStopRequest() 
nsHTTPFinalListener::OnStopRequest() 
InterceptStreamListener::OnStopRequest() 
nsHTTPChannel::ResponseCompleted() 
nsHTTPServerListener::OnStopRequest() 
nsOnStopRequestEvent::HandleEvent() 
nsStreamObserverEvent::HandlePLEvent() 
PL_HandleEvent() 
PL_ProcessPendingEvents() 
nsEventQueueImpl::ProcessPendingEvents() 
event_processor_callback() 
our_gdk_io_invoke() 
libglib-1.2.so.0 + 0x101a0 (0x4068b1a0) 
libglib-1.2.so.0 + 0x11987 (0x4068c987) 
libglib-1.2.so.0 + 0x12001 (0x4068d001) 
libglib-1.2.so.0 + 0x121cc (0x4068d1cc) 
libgtk-1.2.so.0 + 0x93f87 (0x405a6f87) 
nsAppShell::Run() 
nsAppShellService::Run() 
main1() 
main() 
libc.so.6 + 0x1bf31 (0x40253f31) 

Comment 3

[Doug Turner (:dougt)]

Scott, unix-only unknown content type crasher... do you have any bugs that sound
link this?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I reported a similar crash as bug 68910, which has a little info from gdb.

Comment 5

[Doug Turner (:dougt)]

the unknown content decoder is firing an OnDataAvailable when there isn't any
data.  This causes the parser to read from an empty stream.  It barfs in this
case.  

The stream converter shouldn't be firing an oda when there isn't data, but the
parser should be happy with this condition.  

I will attach a diff to fix the stream converter.  Jud, can you r= this?

Comment 6

[Doug Turner (:dougt)]

Attachment: Prevents the UnknownDecoder from firing ODA if there isn't data.

Comment 7

[Doug Turner (:dougt)]

Attachment: Prevents the UnknownDecoder from firing ODA if there isn't data.

Comment 8

[Judson Valeski]

if nsUnknownDecoder::OnDataAvailable() gets called, then that call should be
propegated. nsUnknownDecoder is just an intermediary. Should we burying the
protocol level OnDataAvailable() if there's no data?

Comment 9

[Doug Turner (:dougt)]

actually not.  the firing on OnDataAvailable can come during an OnStopRequest()
if the content type is unknown. 

Comment 10

[Judson Valeski]

gotcha. r=valeski

Comment 11

[Darin Fisher]

sr=darin

Comment 12

[Doug Turner (:dougt)]

Fix checked in.

Comment 13

[rpotts (gone)]

Attachment: Better patch that avoids an ASSERTION if (mBufferLen == 0)

Comment 14

[rpotts (gone)]

I've just attached a better patch that avoids an assertion in the failure case
where OnStopRequest(...) is called with an NS_ERROR status code...  When this
happens, (len == mBufferLen == 0) which caused an ASSERT saying "Unable to write
all the data into the pipe."

In addition to fixing the assert problem, it also addresses bug #37001.

Here, the stack was blowing out because the UnknownDecoder was being recursively
created !  The problem was that the call to nsIChannel::SetContentType() was
failing, but the return code was not being checked...  This caused the
URILoader's OnStartRequest() to get called with the content-type of the channel
still being application/x-unknown-content...  So, another UnknownDecoder would
be created to sniff out the content :-(

Of course, the fix is to check the return code and fail if the content-type
cannot be set.  I believe that this has become more of a problem recently
because the SetContentType() implementation in nsHTTPChannel has been rewritten.

Comment 15

[rpotts (gone)]

I'll take this one :-)

Comment 16

[rpotts (gone)]

patch checked in.

Comment 17

[Bradley Baetz (:bbaetz)]

VERIFIED on branch 2001060713 linux build. Leaving as resolved until the other
platforms are checked.

Comment 18

[greer]

Reopening. Talkback reports are showing this one again in M092 and Trunk data. 
No instances yet in N610 but until it goes public we have relatively little 
data coming in on it.

M092 Comments:
     (33565690) Comments: I was trying to view the source of a mail
message that I had opened in its own window.
     (33516764) Comments: trying to view a message that i send myself UTF-8
encodedwith mozilla containing AOUuoa?? and EURO symbols
     (33403829) Comments: in Mozilla mail 0.92 I tried to open an attatchment &
it crashed
     (33270430) Comments: Opening an attachment
     (33220949) Comments: again tried to open an attachment - but a different
one attached to the same mail

Trunk:
     First Appearance Date : 2001-07-23
     Last Appearance Date : 2001-07-30
     First Build ID : 2001072221
     Latest Build ID : 2001072408

(33312775) Comments: Viewing the 2nd attachment in an email message - this had 
a zero size

I've emailed one crasher (33220949) who offered to send his mail in hopes of 
getting repro steps. If he sends anything back I will attach it. Updating 
summary to M092 and Trunk.

Comment 19

[rpotts (gone)]

Is there a new stack trace available with the 092 talkback incidences?

Comment 20

[Jay Patel [:jay]]

Here is a recent stack from the M092 build:

Incident ID 33270430
Stack Signature Distance() 926efaa1
Bug ID
Trigger Time 2001-07-24 04:57:08
User Comments Opening an attachment
Build ID 2001062823
Product ID Netscape6.10
Platform ID LinuxIntel
Stack Trace
Distance()
nsScanner::RewindToMark()
nsParser::Tokenize()
nsParser::ResumeParse()
nsParser::OnDataAvailable()
nsDocumentOpenInfo::OnDataAvailable()
nsMimeBaseEmitter::Complete()
nsStreamConverter::OnStopRequest()
nsImapCacheStreamListener::OnStopRequest()
Process()
OnDataAvailable()
XPTC_InvokeByIndex()
EventHandler()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0x1001e (0x4036901e)
libglib-1.2.so.0 + 0x117f3 (0x4036a7f3)
libglib-1.2.so.0 + 0x11dd9 (0x4036add9)
libglib-1.2.so.0 + 0x11f8c (0x4036af8c)
libgtk-1.2.so.0 + 0x94803 (0x4027f803)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1c177 (0x404ad177)

and from the MozillaTrunk:

Incident ID 33312775
Stack Signature Distance() 1009b3e7
Bug ID
Trigger Time 2001-07-25 02:44:26
User Comments Viewing the 2nd attachment in an email message - this had a zero size
Build ID 2001072408
Product ID MozillaTrunk
Platform ID LinuxIntel
Stack Trace
Distance()
nsScanner::RewindToMark()
nsParser::Tokenize()
nsParser::ResumeParse()
nsParser::OnDataAvailable()
nsDocumentOpenInfo::OnDataAvailable()
nsMimeBaseEmitter::Complete()
nsStreamConverter::OnStopRequest()
nsMsgProtocol::OnStopRequest()
nsMailboxProtocol::OnStopRequest()
nsOnStopRequestEvent::HandleEvent()
nsARequestObserverEvent::HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xe52a (0x4034952a)
libglib-1.2.so.0 + 0xfbe6 (0x4034abe6)
libglib-1.2.so.0 + 0x101a1 (0x4034b1a1)
libglib-1.2.so.0 + 0x10341 (0x4034b341)
libgtk-1.2.so.0 + 0x8c209 (0x40271209)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x189cb (0x404439cb)

Comment 21

[rpotts (gone)]

It looks like this is a slightly different bug.  This time the UnknownDecoder is
not on the stack...  It looks like this time it is nsStreamConverter (in
mail/news) which is calling OnDataAvailable(...) with an empty input stream :-(

take a look at:
http://lxr.mozilla.org/mozilla/source/mailnews/mime/emitters/src/nsMimeBaseEmitter.cpp#855

it looks Available(...) could be returning 0, but we still call ODA(...).

Comment 22

[rpotts (gone)]

-> mscott.  hey scott, i don't know who should own this one :-) 

it looks like nsBaseMimeEmitter::Complete(...) is calling OnDataAvailable(...)
with an empty stream...

-- rick

Comment 23

[Keyser Sose]

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

Comment 24

[Keyser Sose]

Changing component this is happening on many diffenent network connections and
OS/platforms as per bug 89606

Comment 25

[Jan Carpenter]

This stack sig is not showing up in any of the trunk, M092, or M094 topcrash
reports. 

Comment 26

[Jan Carpenter]

marking fixt.

Comment 27

[Jay Patel [:jay]]

Verifying fixed.  There are a few incidents with the Distance stack signature,
but the stack is missing the nsUnknownDecoder lines...

Comment 28

[R.K.Aa.]

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