Closed Bug 336501 Opened 15 years ago Closed 15 years ago

crash if update post containing file to upload [@ nsBufferedInputStream::Read]

Categories

(Core :: Networking, defect)

1.8 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.8.1

People

(Reporter: email6971622, Assigned: darin.moz)

References

Details

(Keywords: crash, verified1.8.0.7, verified1.8.1)

Crash Data

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

Firefox crashes if POST-form with file is submitted and then refreshed.

Reproducible: Always

Steps to Reproduce:
1. create or find the html form with file input
2. submit the form
3. press f5




It's appeared after updating to 1.5.0.3 from 1.5.0.2 with partial update.
Version: unspecified → 1.5.0.x Branch
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

Could possibly be caused by an extension. Are you able to reproduce the crash in safe mode (http://kb.mozillazine.org/Safe_mode) and if so, could you paste the Talkback ID (http://kb.mozillazine.org/Talkback) here?
Keywords: crash
I can't reproduce this bug in Safe Mode. You are right, this is caused by extension. I suppose, by Web Developer Extension (1.0.2). Because it causes other bugs.

I using following extensions:

 * DOM Inspector 1.8.0.3
 * Web Developer 1.0.2
 * Paste and Go 0.4.3
 * Tab Sidebar 1.0.3
 * Live HTTP Headers 0.11

No any updates exists for these extensions.

What else can I do for help you to reproduce this bug on your side?
By enumerative technique (by uninstalling one-by-one) I found which extension crashes firefox, this is "Live HTTP Headers" version 0.11 (latest, as I know).
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
I'd still like a talkback ID if you feel like getting one for the crash. http://kb.mozillazine.org/Talkback
Is there a talkback ID for this crash?
I'm sorry, it's seems I did not install Talkback when installed Firefox. I need to download full version and reinstall firefox. Wait 10 min.
Hmm. I never used Talkback before and maybe I'm doing something wrong, but I've got the Talkback window when firefox was crashed again, there was a form with my email and details. I filled it out, placed link to this bug in details and pressed Send. After data is sent - the window has been disappered without any confirmation dialog and I did not got any IDs. "Talkback ID" - it must be a number, yes?
TB18348159:

Stack Signature	 msvcrt.dll + 0x36fa3 (0x77c36fa3) e98e3c05
Product ID	Firefox15
Build ID	2006042618
Trigger Time	2006-05-05 14:47:11.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	msvcrt.dll + (00036fa3)
URL visited	
User Comments	This is a talkback id generated specially for bug #336501 https://bugzilla.mozilla.org/show_bug.cgi?id=336501
Since Last Crash	174 sec
Total Uptime	174 sec
Trigger Reason	Access violation
Source File, Line No.	N/A
Stack Trace 	
msvcrt.dll + 0x36fa3 (0x77c36fa3)
nsBufferedInputStream::Read  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsBufferedStreams.cpp, line 316]
nsMultiplexInputStream::Read  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/xpcom/io/nsMultiplexInputStream.cpp, line 200]
nsMultiplexInputStream::Read  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/xpcom/io/nsMultiplexInputStream.cpp, line 200]
nsMIMEInputStream::Read  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsMIMEInputStream.cpp, line 262]
nsBufferedInputStream::Fill  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsBufferedStreams.cpp, line 388]
nsBufferedInputStream::ReadSegments  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsBufferedStreams.cpp, line 351]
nsHttpTransaction::ReadSegments  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpTransaction.cpp, line 392]
nsHttpConnection::OnSocketWritable  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnection.cpp, line 559]
nsHttpConnection::OnOutputStreamReady  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/protocol/http/src/nsHttpConnection.cpp, line 771]
nsSocketTransport::OnSocketReady  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/netwerk/base/src/nsSocketTransport2.cpp, line 1469]
nsThread::Main  [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/xpcom/threads/nsThread.cpp, line 134]
kernel32.dll + 0xb50b (0x7c80b50b)
Darin, biesi, any ideas?
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
*** Bug 334641 has been marked as a duplicate of this bug. ***
See also bug 290003.
Component: General → Networking
Product: Firefox → Core
Version: 1.5.0.x Branch → 1.8 Branch
QA Contact: general → networking
Summary: crash if update post containing file to upload → crash if update post containing file to upload [@ nsBufferedInputStream::Read]
*** Bug 336382 has been marked as a duplicate of this bug. ***
Note: reporter of bug 336382 (marked duplicate of this one) says he can reproduce the crash in safe mode by uploading an image to http://brotherli.ch/temp/base64.php and reloading using F5.
I have sent TB19713030Q after realoading a POST with a file. 
Now I've uninstalled Live HTTP Headers and Firefox no longer crash

(winXP Sp2, Firefox 1.5.0.4)
What's the URI to the "Live HTTP Headers" extension?

Also, I suspect there may be two separate issues here -- one with Live HTTP Headers, and a separate issue for bug 336382.  I'll reopen that bug.
Blocks: 336382
So would it be relevant that Live HTTP Headers closes the POST data stream?  The relevant code is in the visitPostHeaders() function in this file.
Ah, yeah.  That's it.  No wonder I couldn't reproduce this on trunk!

On branch, if someone calls nsBufferedInputStream::Close that will call nsBufferedStream::Close which deletes mBuffer and sets it to null and sets mCursor to 0.  It does NOT change mFillPoint, however.

Then nsBufferedInputStream::Read is called.  If mFillPoint > mCursor, it memcopies from mBuffer + mCursor.  This pointer is null if Close() has been called, so we crash.

We should probably at least set mFillPoint to 0 in nsBufferedStream::Close on branch...  Once that's done, we might have to adjust Read and ReadSegments a tad to deal with that.

Alternately, we could null-check mStream up front in Read and ReadSegments and bail out if it's null.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.1?
Flags: blocking1.8.0.5?
*** Bug 341222 has been marked as a duplicate of this bug. ***
it seems more important to fix livehttpheaders not to close the stream, because as long as it does so that will probably trigger incorrect behaviour in mozilla in various places.
Well.  We should be doing both.  http://mozdev.org/bugs/show_bug.cgi?id=12050 covers the LiveHTTPHeaders end of things; I just commented there.
Assignee: nobody → darin
Flags: blocking1.8.0.5? → blocking1.8.0.5+
Not blocking 1.8.0.x but would consider approving a safe patch.
Flags: blocking1.8.0.5+ → blocking1.8.0.5-
I'll add some null checks internally to harden us against extensions like this.
Status: NEW → ASSIGNED
Flags: blocking1.8.1? → blocking1.8.1+
Target Milestone: --- → mozilla1.8.1
Attached patch v1 patchSplinter Review
Attachment #226712 - Flags: superreview?(bzbarsky)
Attachment #226712 - Flags: review?(bzbarsky)
Comment on attachment 226712 [details] [diff] [review]
v1 patch

Looks good.
Attachment #226712 - Flags: superreview?(bzbarsky)
Attachment #226712 - Flags: superreview+
Attachment #226712 - Flags: review?(bzbarsky)
Attachment #226712 - Flags: review+
Regression test added to the trunk.
Attachment #226712 - Flags: approval1.8.1?
Attachment #226712 - Flags: approval1.8.1? → approval1.8.1+
fixed1.8.1
Status: ASSIGNED → RESOLVED
Closed: 15 years ago15 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
*** Bug 342820 has been marked as a duplicate of this bug. ***
*** Bug 336382 has been marked as a duplicate of this bug. ***
No longer blocks: 336382
*** Bug 343625 has been marked as a duplicate of this bug. ***
Nominating for the next 1.5 release since there's a patch now.
Flags: blocking1.8.0.6?
Attachment #226712 - Flags: approval1.8.0.6?
*** Bug 278086 has been marked as a duplicate of this bug. ***
*** Bug 346065 has been marked as a duplicate of this bug. ***
Comment on attachment 226712 [details] [diff] [review]
v1 patch

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #226712 - Flags: approval1.8.0.7? → approval1.8.0.7+
Flags: blocking1.8.0.7? → blocking1.8.0.7+
fixed1.8.0.7
Keywords: fixed1.8.0.7
This is a one line fix to set mFillPoint = 0.

Verified by inspection for 1.8.0.7 and 1.8.1.
*** Bug 352634 has been marked as a duplicate of this bug. ***
*** Bug 334271 has been marked as a duplicate of this bug. ***
Flags: in-testsuite+
Crash Signature: [@ nsBufferedInputStream::Read]
You need to log in before you can comment on or make changes to this bug.