Closed Bug 85823 Opened 23 years ago Closed 23 years ago

Mozilla crashing in [@ nsHttpConnection::ReportProgress]

Categories

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

x86
Windows 2000
defect

Tracking

()

VERIFIED DUPLICATE of bug 85822
mozilla0.9.2

People

(Reporter: scb147, Assigned: darin.moz)

Details

(Keywords: crash, topcrash)

Crash Data

This bug happens on a random basis. It happens in mail/news and in the browser component. The Windows error says something to the effect that the memory cannot be read or written to. I have removed all mozilla traces on my system and registry, and I rebuilt my profile, and it still happens. OS: Win2k SP2 Moz Build: 2001061304 Win32 Talkback User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1+) Gecko/20010613
Stack Signature nsHttpConnection::ReportProgress 8960cf4f Bug ID Trigger Time 2001-06-13 18:53:32 User Comments Build ID 2001061309 Product ID MozillaTrunk Platform ID Win32 Stack Trace nsHttpConnection::ReportProgress [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpConnection.cpp, line 304] nsHttpTransaction::Read [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpTransaction.cpp] nsHttpTransaction::Read [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpTransaction.cpp] nsReadFromInputStream [d:\builds\seamonkey\mozilla\xpcom\io\nsPipe2.cpp, line 831] nsPipe::nsPipeOutputStream::WriteSegments [d:\builds\seamonkey\mozilla\xpcom\io\nsPipe2.cpp, line 705] nsPipe::nsPipeOutputStream::WriteFrom [d:\builds\seamonkey\mozilla\xpcom\io\nsPipe2.cpp, line 839] nsReadFromInputStream [d:\builds\seamonkey\mozilla\xpcom\io\nsPipe2.cpp, line 828] nsHttpTransaction::OnDataReadable [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpTransaction.cpp, line 185] nsHttpConnection::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHttpConnection.cpp, line 580]
Status: UNCONFIRMED → NEW
Ever confirmed: true
-> me
Assignee: neeti → darin
Keywords: crash
Target Milestone: --- → mozilla0.9.2
Severity: normal → blocker
Priority: -- → P1
I believe this is another example of cancelation not being threadsafe. BTW: we cancel transactions for a variety of reasons, not just because the user presses cancel. redirects cause transactions to be canceled often when they still have data, which i suspect is the case here. in nsHttpTransaction::Cancel, we clear mConnection, but in nsHttpTransaction::Read (which is called on the socket thread) we end up calling nsHttpConnection::ReportProgress on mConnection. i suspect that mConnection is null by the time this code is reached. so, this is likely a dupe of bug 85822
Status: NEW → ASSIGNED
marking as dupe of 85822, please reopen if crashes with this stack trace persist. *** This bug has been marked as a duplicate of 85822 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Adding topcrash for talkback tracking
Keywords: topcrash
Sorry for the spam: changing the summary to include [@ ] on the signature to help talkback tracking.
Summary: Mozilla crashing in nsHttpConnection::ReportProgress → Mozilla crashing in [@ nsHttpConnection::ReportProgress]
VERFIFIED: My limited debugging skills agree...
Status: RESOLVED → VERIFIED
Crash Signature: [@ nsHttpConnection::ReportProgress]
You need to log in before you can comment on or make changes to this bug.