120628 - Crash on submitting form

Status: VERIFIED DUPLICATE of bug 103757

(Core :: Networking: HTTP, defect)

Description

[Bob Clary [:bc] (inactive)]

Steps to reproduce:
1. enter a bogus user id and password
2. click Go to submit form.

Results:
Crash
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+) Gecko/20020111

Reproducible:
Everytime

Several errors occur and no talkback is generated.

Comment 1

[Olav Vitters]

Attachment: Stacktrace Linux todays CVS

Also saw the following assertion:
Error loading URL https://www.enthusian.com/template/loginProcess.cfm :
804b0002
###!!! ASSERTION: Wrong Document Channel: 'request == mDocumentRequest', file
nsDocLoader.cpp, line 1292
###!!! Break: at file nsDocLoader.cpp, line 1292

Comment 2

[Matthias Versen [:Matti]]

-> Networking:http 

Comment 3

[Robert Seifert]

I see this crash in Windows XP too, using build 2002011604

Comment 4

[timeless]

can you please try nspr logging?
NSPR_LOG_MODULES http:5 [i think that's the syntax]

Comment 5

[Olav Vitters]

Attachment: HTTP log (95kB)

Adding http log, made with:
set NSPR_LOG_MODULES=nsHttp:5
set NSPR_LOG_FILE=http.log

Comment 6

[Darin Fisher]

-> badami

Comment 7

[Vinay Badami]

Darin

Looks like after entering in an invalid username/passwd, 3 nsHttpTransaction
objects that get created.
On the last one, we seem to be getting the body with no reponse status-line/headers.
This causes us to fail quite badly while looking for the beginning HTTP of the
status line. We find the HTTP in <META HTTP.
The reason for the failure is that in nsHttpTransaction::ParseHead count -
*countRead turns out to be -ve and since they are unsigned integers becomes a
huge +ve value.

While we could error out if *countRead > count, I first want a second opinion
that this is actually what is happenning. 

Comment 8

[Vinay Badami]

Attachment: Prevent crash if *countRead > count

If for anyreason *countRead > count, then return early and prevent crashes as a
result of count - *countRead becoming -ve, and since they are unsigned
resulting in a huge +ve number.

Comment 9

[Vinay Badami]

Looks like IE and NS4.7 work fine with this site.
So there is certainly something fishy on our end.

Comment 10

[Darin Fisher]

vinay: actually, i have a feeling that this line might be the culprit:

   count -= *countRead;

there is code that tries to ignore some garbage before the status line... it
searches forward for the string HTTP.  unfortunately, that seems to be matching
the wrong thing in this case, because the response is really HTTP/0.9... ie.
sent without any headers.

Comment 11

[Vinay Badami]

Attachment: purify log

Lost of fatal errors in the purify log

Comment 12

[Vinay Badami]

Lost ==> lots

1. Purify logs indicate a lot of fatal errors.
2. Although as far as looking at the n/w bytes from the debugger, comment #7 is
still valid, given that 
a. IE, Nav4.7 work fine.
b. Given the purify errors, I'am not convinced that the problem is that the
server is returning back just the body and no status-line/headers. Also, looks
like the server we are talking to is IIS that has identified itself already as
1.1 server. So it cannot be sending back 0.9 responses.

3. At the end of this there may still be an issue with nsHttpTransaction::ParseHead.
4. Always keep getting the assertion 
###!!! ASSERTION: Wrong Document Channel: 'request == mDocumentRequest', file
nsDocLoader.cpp, line 1292
###!!! Break: at file nsDocLoader.cpp, line 1292

Can we get someone from the docloader/XMLdocument groups to take a look at the
above ?

Comment 13

[Darin Fisher]

*** This bug has been marked as a duplicate of 103757 ***

Comment 14

[John Unruh]

Verified dupe.