254181 - ###!!! ASSERTION: PushBack: 'Not Reached', file /home/chb/mozilla/netwerk/protocol/http/src/nsHttpConnection.h, line 118

Status: RESOLVED DUPLICATE of bug 629458

(Core :: Networking: HTTP, defect, P5)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

###!!! ASSERTION: PushBack: 'Not Reached', file
/home/chb/mozilla/netwerk/protocol/http/src/nsHttpConnection.h, line 118

steps to reproduce: load http://movies.go.com/trailers/index.html in a debug build

Note: This may require having realplayer 10 + plugin installed

tested in a gtk2+xft build, current cvs

this assertion is reproducable.

Comment 1

[Darin Fisher]

do you have pipelining enabled?

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

no... just http/1.1 + keep-alive.

Comment 3

[Darin Fisher]

I'm able to reproduce this under Win2k as well.

Comment 4

[Darin Fisher]

stack trace on win2k:

nsHttpConnection::PushBack(const char * 0x0375ba45, unsigned int 2) line 118 +
30 bytes
nsHttpConnectionMgr::nsConnectionHandle::PushBack(const char * 0x0375ba45,
unsigned int 2) line 935
nsHttpTransaction::ProcessData(char * 0x0375ba44, unsigned int 3, unsigned int *
0x01bbfe34) line 900
...

looks like there are two bytes being passed to the PushBack function: 0xA, 0x20

it's not clear if these are simply extra garbage in the response or if they are
not being consumed properly by our code.

Comment 5

[Darin Fisher]

ok, so in this case the server is sending us some junk.  an ethereal trace shows
the following response:

HTTP/1.1 200 OK\r\n
Cache-control: no-cache\r\n
Pragma: no-cache\r\n
Expires: 0\r\n
Content-Length: 1\r\n
Content-Type: application/x-javascript\r\n
\r\n
\r\n
\x20

and that's it.  notice that the content-length header does not match the size of
the response body.  there's 2 extra bytes: \n and \x20

the assertion in our code indicates that we are discarding the extra data, and
in this case that's probably the right thing to do.  though it's not really good
to assert when things are "ok" ... hmm

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

hm, same as bug 240076 it seems, but that's tech evang; we should probably not
assert just because untrusted input is bad...

Comment 7

[Jesse Ruderman]

http://movies.go.com/trailers/index.html is gone (perhaps replaced by http://movies.go.com/movie_trailers, which doesn't trigger the assertion).

Since it sounds like it's normal for bad server data to trigger this assertion, it should probably be removed or turned into a warning...

Comment 8

[Jesse Ruderman]

Attachment: jesse's stack trace

I hit this assertion once while loading http://bloodistruth.blogspot.com/, but can't reproduce at will.  Here's my stack trace.