Closed Bug 290003 Opened 20 years ago Closed 19 years ago

Firefox crashes everytime i upload a file [@ nsBufferedInputStream::Read ]

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: fishywang, Assigned: darin.moz)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

A French version(en locale included) of the extension
14.91 KB, application/octet-stream
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Every time I use firefox to upload a file (such as some blog system or add a
attachment here), it crashes :(


Reproducible: Always




AppName: firefox.exe	 AppVer: 1.0.2.0	 ModName: msvcrt.dll
ModVer: 7.0.2600.2180	 Offset: 00036fe2
Yuxuan Wang: Could you please provide Talkback incident of your crash?
Severity: normal → critical
Keywords: crash
Version: unspecified → 1.0 Branch
I've turned on my talkback agent and sent things automatically every time. how
to provide more informations?
Start the talkback application (it's located in the components directory of your
firefox installation). The colum "Incident ID" contains the requested information.
the most recent 2 crashes are:
TB5024562E
TB5021494Z

hope it helps :-)
Incident ID: 5021494
Stack Signature	msvcrt.dll + 0x37032 (0x77c47032) 1baeb570
Product ID	Firefox10
Build ID	2005031717
Trigger Time	2005-04-11 18:30:27.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	msvcrt.dll + (00037032)
URL visited	
User Comments	
Since Last Crash	79168 sec
Total Uptime	165898 sec
Trigger Reason	Access violation
Source File, Line No.	N/A

Stack Trace 	
msvcrt.dll + 0x37032 (0x77c47032)
nsBufferedInputStream::Read 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsBufferedStreams.cpp,
line 309]
nsMultiplexInputStream::Read 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/io/nsMultiplexInputStream.cpp,
line 199]
nsMultiplexInputStream::Read 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/io/nsMultiplexInputStream.cpp,
line 199]
nsMIMEInputStream::Read 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsMIMEInputStream.cpp,
line 262]
XPTC_InvokeByIndex 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2034]
XPC_WN_CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 949]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2993]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 966]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2993]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 966]
nsXPCWrappedJSClass::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1339]
nsXPCWrappedJS::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
nsEventListenerManager::HandleEventSubType 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1516]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2841]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleChromeEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 3988]
GlobalWindowImpl::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 916]
DocumentViewerImpl::LoadComplete 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsDocumentViewer.cpp,
line 917]
nsDocShell::EndPageLoad 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 4602]
nsWebShell::EndPageLoad 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsWebShell.cpp,
line 755]
nsDocShell::OnStateChange 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/docshell/base/nsDocShell.cpp,
line 4536]
nsDocLoaderImpl::FireOnStateChange 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 1252]
nsDocLoaderImpl::doStopDocumentLoad 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 873]
nsDocLoaderImpl::OnStopRequest 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/uriloader/base/nsDocLoader.cpp,
line 701]
nsLoadGroup::RemoveRequest 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/netwerk/base/src/nsLoadGroup.cpp,
line 695]
HandleImagePLEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsImageLoadingContent.cpp,
line 582]
PL_HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/threads/plevent.c,
line 674]
shdocvw.dll + 0x150c24 (0x778b0c24)
nsPagePrintTimer::StartTimer 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsPagePrintTimer.cpp,
line 70]
0x57036a08
Summary: Firefox crashes everytime i upload a file → Firefox crashes everytime i upload a file [@ nsBufferedInputStream::Read ]
btw. It seems that the dll offset 0x36fe2 and 0x37032 are both behind the entry
point of memcpy.
Crash also on GNU/Linux with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050510
(and also with a 2005-04-05 nightly)

TB5768519E
Hope it helps.
Last two Incident ID's:
TB6356741W
TB6424801W

It happends in all 1.0+ versions i have tested.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050602
Firefox/1.0+
Assignee: bugs → darin
Component: OS Integration → Networking
Product: Firefox → Core
QA Contact: os.integration → benc
Version: 1.0 Branch → Trunk
I can confirm.
Everytime I try to upload a file using an input type='file', Firefox crashes.
But not when I have my Live HTTP Headers window open, not when in FF safe mode,
not when using GMail. So it might as well be related to an
as-of-yet-still-unknown Firefox extension.
Confirming for latest trunk (20050727), win32.

Good example site: www.imageshack.us

Will ALWAYS crash when an upload is nearly finished (although the upload is
usually fully uploaded by then).  If you have an account at ImageShack, you can
go back to your images after the crash and find that the image was fully uploaded.
Can anyone reproduce this crash using Firefox in safe-mode?  If so, please tell
me how to reproduce the bug.  If the crash happens because of some extension,
then this bug is most likely INVALID, and you would want to contact the author
of the extension that is misbehaving.
Matt: did you have any extensions installed when you hit this crash?
(In reply to comment #13)
> Matt: did you have any extensions installed when you hit this crash?

Several.  I wouldn't know where to start looking for the problem.
Please try running Firefox in safe mode, and then see if you can reproduce the
problem.  Just pass "-safe-mode" on the command line when launching Firefox.
In safe mode it's ok, so that must be a extension's problem. I'm sorry for this
bug report.
but I've installed so many extensions, is there any way to find out the
extension quickly(or I can only disable every extension and test)?
I've found that it's Crash Recovery's fault
OK, can you please inform the author of the "Crash Recovery" extension?  Thanks
for taking the time to investigate this crash.  Marking this bug INVALID.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
darin: js extensions really shouldn't be able to easily crash mozilla. most of
the crashes that they can cause indicate bad code which should be fixed, albeit
not necessarily as urgently as other bad code in mozilla.

reporter: unfortunately it seems the extension you've indicated is mostly
unavailable. if it's tiny enough and you have the xpi you used, could you attach it?
This is a French version I've found by Google
I've tested the French version I uploaded, it can DO crash fx after uploading
I experience this bug, too, but I don't use Crash Recovery. But I use
SessionSaver .2 (which is probably at least similar to that). I have tested on a
fresh Firefox installation with only a few plugins (including SessionSaver) and
the uploads work fine. Then, I found that probably the _combination_ of Live
HTTP Headers and SessionSaver seems to be at fault.

So -- if you have both of them installed, try uninstalling any one of them, it
could help.
After uninstalling Crash Recovery, I've installed Session Saver .2, and I've
installed LiveHTTPHeader before, but my Fx won't crash after uploading now.
> darin: js extensions really shouldn't be able to easily crash mozilla. most of
> the crashes that they can cause indicate bad code which should be fixed, albeit
> not necessarily as urgently as other bad code in mozilla.

timeless: Yes, sometimes (often) that is true.  If someone wants to figure what
API the extension is abusing, then I'll happily work to make the API more robust.
The stack trace in comment #5 is very confusing because it indicates that
Javascript is invoking nsMIMEInputStream::Read, which is a non-scriptable method!
*** Bug 316963 has been marked as a duplicate of this bug. ***
I had this bug with Session Saver too. After uninstalling it bug did not happen anymore. After installing Session Saver .2 d1 nightly 30 (development version) it did not reappear - so I guess it is triggered by something that was in previous versions of Session Saver.
(In reply to comment #25)
> The stack trace in comment #5 is very confusing because it indicates that
> Javascript is invoking nsMIMEInputStream::Read, which is a non-scriptable method!

Actually, I think all it would have to do is call read() from nsIScriptableInputStream which would, in effect, call nsMIMEInputStream::Read.
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/xpcom/io/nsScriptableInputStream.cpp&rev=1.9&mark=80#65

So somehow memcpy() get's an invalid memory address, then fails?
so, when you see missing frames, it's usually tail call optimization, with that assumption, you have two choices according to mxr-test:
http://landfill.mozilla.org/mxr-test/mozilla/search?string=%3Eread%28&find=%5C.cpp%24&filter=return.*read

/netwerk/base/src/nsBufferedStreams.cpp, line 606 -- return fromStream->Read(toRawSegment, count, readCount);
/xpcom/io/nsPipe3.cpp, line 1156 -- return fromStream->Read(toRawSegment, count, readCount);

Deciding which of those lines are in scriptable methods or in tail call reachable scriptable methods is left as an exercise for ispiked :).
Crash Signature: [@ nsBufferedInputStream::Read ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: