segmentation fault on retrieving data

RESOLVED WORKSFORME

Status

()

Core
Networking: HTTP
--
critical
RESOLVED WORKSFORME
16 years ago
15 years ago

People

(Reporter: Jan Ludewig, Assigned: Darin Fisher)

Tracking

({crash, helpwanted})

Trunk
x86
FreeBSD
crash, helpwanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: checkMac, checkWin, checkLinux, URL)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.7) Gecko/20020120
BuildID:    20020202

Sending an ascii-string to the browser without mime-type causes mozilla to crash
with a segmentation fault if that strings contains the
character sequence '(https)'.




Reproducible: Always
Steps to Reproduce:
1. Create a file like this:
<content>foofoo (https)</content>
2. Make this file to be sent to the browser (I used /bin/cat in inetd.conf for
the service 'http')
3. Request it with mozilla

Actual Results:  Mozilla crashes with a segmentation fault.

Expected Results:  Display the file as plain text.

a) It crashes only if there are enough characters that precede the '(https)'
b) It does not crash, if the string in brackets is not 'https'.
c) It has been verified on windows as well.
d) The buildID is wrong, mine is not displayed, but the bug has been verified by
various people in IRC.
Stack trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1026 (LWP 5583)]
0x4069d500 in memchr () at ../../../dist/include/xpcom/nsCOMPtr.h:410
410
      NS_EXPORT ~nsCOMPtr_base() { }
(gdb) bt
#0  0x4069d500 in memchr () at ../../../dist/include/xpcom/nsCOMPtr.h:410
#1  0x40cb72bc in nsHttpConnection::nsIStreamListener virtual table () at
../../../dist/include/xpcom/nsCOMPtr.h:410
#2  0x40c3cb57 in nsHttpTransaction::Read (this=0x8695a38, buf=0x42200fd0
"foofoo (https)\n", count=15, bytesWritten=0xbf7ff840)
    at /part2/mozilla/netwerk/protocol/http/src/nsHttpTransaction.cpp:866
#3  0x40200fa4 in nsReadFromInputStream (outStr=0x869293c, closure=0x8695a40,
toRawSegment=0x42200fd0 "foofoo (https)\n", offset=0, 
    count=4096, readCount=0xbf7ff840) at /part2/mozilla/xpcom/io/nsPipe2.cpp:847
#4  0x40200af3 in nsPipe::nsPipeOutputStream::WriteSegments (this=0x869293c, 
    reader=0x40200f80 <nsReadFromInputStream(nsIOutputStream *, void *, char *,
unsigned int, unsigned int, unsigned int *)>, 
    closure=0x8695a40, count=16384, writeCount=0xbf7ff924) at
/part2/mozilla/xpcom/io/nsPipe2.cpp:721
#5  0x40200fe2 in nsPipe::nsPipeOutputStream::WriteFrom (this=0x869293c,
fromStream=0x8695a40, count=16384, writeCount=0xbf7ff924)
    at /part2/mozilla/xpcom/io/nsPipe2.cpp:855
#6  0x40c02d16 in nsStreamListenerProxy::OnDataAvailable (this=0x86949e0,
request=0x8695a3c, context=0x0, source=0x8695a40, offset=0, 
    count=16384) at /part2/mozilla/netwerk/base/src/nsStreamListenerProxy.cpp:303
#7  0x40c3b0fc in nsHttpTransaction::OnDataReadable (this=0x8695a38, is=0x422006b0)
    at /part2/mozilla/netwerk/protocol/http/src/nsHttpTransaction.cpp:241
#8  0x40c3a1bb in nsHttpConnection::OnDataAvailable (this=0x42200b78,
request=0x42200d60, context=0x0, inputStream=0x422006b0, offset=0, 
    count=8192) at /part2/mozilla/netwerk/protocol/http/src/nsHttpConnection.cpp:697
#9  0x40bfd802 in nsSocketReadRequest::OnRead (this=0x42200d60) at
/part2/mozilla/netwerk/base/src/nsSocketTransport.cpp:2871
#10 0x40bf8517 in nsSocketTransport::doReadWrite (this=0x42200c28, aSelectFlags=1)
    at /part2/mozilla/netwerk/base/src/nsSocketTransport.cpp:1077
#11 0x40bf70d8 in nsSocketTransport::Process (this=0x42200c28, aSelectFlags=1)
at /part2/mozilla/netwerk/base/src/nsSocketTransport.cpp:541
#12 0x40bfed65 in nsSocketTransportService::Run (this=0x8123758) at
/part2/mozilla/netwerk/base/src/nsSocketTransportService.cpp:516
#13 0x402253d0 in nsThread::Main (arg=0x8133518) at
/part2/mozilla/xpcom/threads/nsThread.cpp:120
#14 0x403079c2 in _pt_root (arg=0x812d8f8) at
/part2/mozilla/nsprpub/pr/src/pthreads/ptthread.c:214
#15 0x4032fe24 in pthread_start_thread_event (arg=0xbf7ffc00) at manager.c:274

Comment 2

16 years ago
Works for me 0.9.8 / Mac OS X CFM
-> Networking
Assignee: asa → new-network-bugs
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: doronr → benc

Comment 4

16 years ago
are either of you still seeing this?  With my first attempt at reproducing it
seems  to be working.

Comment 5

16 years ago
reporter:

Can you provide more information about how you did this? Are you saying that you
hacked your inetd config so that the file would be cat'd into a request on HTTP? 

You should post your file as an attachment in bugzilla (and/or) check the
content on a web server.

Thomas: thanks for the Mac data.

tever: what platform did you check?
Keywords: qawanted

Comment 6

16 years ago
reporter: we are going to need more information to assign the bug to an engineer

Please update w/ RC1 data, and answer the questions above.

Comment 7

16 years ago
status changed to reflect need to check popular platforms.

If you can get someone to confirm they have this problem on other platforms, you
increase the chance of a fix.
Whiteboard: checkMac, checkWin, checkLinux

Updated

16 years ago
Keywords: crash, helpwanted

Comment 8

16 years ago
neeti: this needs to be analyzed.

mail from reporter:

On Fri, Apr 26, 2002 at 09:26:46AM -0700, Benjamin Chuang wrote:

> >to comment 5:
> > - Yes, i hacked inetd.conf to 'cat' the file as data to be sent on all
> > established tcp connections to port 80. The application level protocol
> > used over this tcp connection does not matter at all. All data sent by the
> > client is ignored.
> >

> That is because you cannot just present the file via cat. You have to 
> include HTTP headers in the response.


Some definitions of 'hacking' say it is 'using things in another way than 
the intended one' ;)


> Can you post detailed steps as to how you configured this service, as 
> well as the file you actually sent that caused a crash?


Server Setup:
=============
a) Jail on a i686 FreeBSD Box with 4.5 Release kernel and 4.4 Release userland.
b) i686 FreeBSD-Current Box

#### /etc/inetd.conf:
http    stream  tcp     nowait  root    /bin/cat cat /NO_HTTP{NEWLINE}
####

### /NO_HTTP (also via: http://archiv.infopeace.de/jl/NO_HTTP_Mozilla.crash)
secure connection only (https){NEWLINE}{EOF}
###
(with newlines and eof visualized => omit  /{[^}]+}/)

Reproduce:
==========
1) edit inetd.conf as shown above
2) create /NO_HTTP as shown above
3) start inetd
4) point mozilla to the host and port our 'customized service' listens to.


> If this was not a crash, I really would not care, but I think the WFM 
> people have not been doing what you have been doing.

Well, insufficient input validation still seems to be the holy grail of 
morology :(

Comment 9

16 years ago
cc'ing darin
Component: Networking → Networking: HTTP

Comment 10

16 years ago
neeti: please update the owner and qa when you move a bug to a new 
component.
Assignee: new-network-bugs → darin
QA Contact: benc → tever
(Assignee)

Comment 11

16 years ago
some code changes went in since 2/14 that might have cleared up this crash.  can
someone confirm this crash with a recent nightly build?  thx!
(Assignee)

Comment 12

16 years ago
WFM (build 1.0.0-20020514 linux)
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 13

15 years ago
qa to me. (sigh)
Keywords: qawanted
QA Contact: tever → httpqa
You need to log in before you can comment on or make changes to this bug.