[1.8 branch] Crash while uploading files to MediaFire.com [@ nsXMLHttpRequest::ConvertBodyToText]

RESOLVED DUPLICATE of bug 390219

Status

()

Core
General
--
critical
RESOLVED DUPLICATE of bug 390219
9 years ago
6 years ago

People

(Reporter: R P Mozley, Assigned: bz)

Tracking

({crash, regression, verified1.8.1.18})

1.8 Branch
All
Mac OS X
crash, regression, verified1.8.1.18
Points:
---
Bug Flags:
blocking1.8.1.18 +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.1.17) Gecko/20080916 Camino/1.6.4 (like Firefox/2.0.0.17)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.1.17) Gecko/20080904 Firefox/2.0.0.17

If you try to upload a file or files to MediaFire.com using their "basic uploader" Firefox 2.0.0.17 will crash. It also crashes in SeaMonkey 1.1.12 and Camino 1.6.4
This leads me to believe that it is a core Gecko bug in the 1.8.1 branch. On testing with previous builds in the Gecko 1.8.1.16 family MediaFire.com does not crash.
There for the bug must have been introduce within the code changes of Gecko 1.8.1.17
One possiblilty is Bug 439034 [https://bugzilla.mozilla.org/show_bug.cgi?id=439034]

Reproducible: Always

Steps to Reproduce:
1. Switch to MediaFire's "basic uploader"
2. Try uploading a few files of medium size (10MB+)
3. Uploader will run for a few moments, then Firefox crashes
Actual Results:  
Firefox-bin crashes, writing to crash log

Expected Results:  
Files get uploaded to MediaFire.com

Here is a crash log of Firefox 2.0.0.17:
http://pastebin.mozilla.org/542614

And of Camino 1.6.4:
http://pastebin.mozilla.org/542572
(Reporter)

Updated

9 years ago
Version: unspecified → 2.0 Branch

Comment 1

9 years ago
Can you attach teh crash log(s) to this bug (use the 'Add and attachment' link) so that they don't get lost ? Thanks.
Component: General → General
Keywords: regression
Product: Firefox → Core
QA Contact: general → general
Summary: Crash while uploading files to MediaFire.com → [1.8 branch] Crash while uploading files to MediaFire.com
Version: 2.0 Branch → 1.8 Branch
(Reporter)

Comment 2

9 years ago
Created attachment 340724 [details]
Firefox crash log
(Reporter)

Comment 3

9 years ago
Created attachment 340725 [details]
Camino crash log
(Reporter)

Comment 4

9 years ago
Created attachment 340726 [details]
SeaMonkey crash log
I can confirm this crash , 2.0.0.16 is fine with the steps to reproduce, 2.0.0.17 crashs.

I will search for the Regression Window
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Does it also happen on Windows and Linux? Similar to bug 456705?
Summary: [1.8 branch] Crash while uploading files to MediaFire.com → [1.8 branch] Crash while uploading files to MediaFire.com [@ nsXMLHttpRequest::ConvertBodyToText]
Nominating since this is a crash-regression on the branch.
Flags: blocking1.8.1.18?
Same regression range as in Bug 456705 - 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.17pre) Gecko/2008082603 BonEcho/2.0.0.17pre -> works

Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.17pre) Gecko/2008082703 BonEcho/2.0.0.17pre -> crashs

also i got Error: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: http://www.mediafire.com/upload_timer.html :: anonymous :: line 2"  data: no]
Source File: http://www.mediafire.com/upload_timer.html
Line: 2

in the Firefox Error Console.
bz: see comment 8
Blocks: 445890
Huh.  Odd.  The patch in bug 445890 should not have affected either .status or ConvertBodyToText.

Does one need a MediaFire account to reproduce this bug?  If so, is there any chance of a breakpad incident id or some other stack that actually has line numbers?
Boris, it looks like anyone can reproduce this by visiting the site in a 1.8.1-branch build and following the steps in comment 0 (the "switch to basic uploader" link is on the right side underneath the big green "Upload Files to MediaFire" button).  In Camino 1.6.4, made the uploader start to upload the latest Camino.dmg and the uploader crashed Camino.  (Unfortunately, I can't get you a crash log with line numbers because my 1.8.1-branch debug build crashes with some JS_Assert failure just loading the mediafire page.)
(In reply to comment #10)
> Does one need a MediaFire account to reproduce this bug?  If so, is there any
> chance of a breakpad incident id or some other stack that actually has line
> numbers?

Boris, what I've seen is that you have to upload at least two or three files at once. When I had selected only one file I wasn't able to crash Firefox. Sadly *Talkback* doesn't come up on my system. So I cannot offer any line numbers. I even don't have a debug build.

Tomcat, do you have a 1.8 branch debug build?
(In reply to comment #10)
> Does one need a MediaFire account to reproduce this bug?  If so, is there any
> chance of a breakpad incident id or some other stack that actually has line
> numbers?

Hi Boris, you don't need a mediafire account. Just go to the mediafire site -> choose the basic uploader and and upload a (one! file is enough) file bigger then 10MB and you crash.

Unfortunately my Mac Debug Build crash with the same stack as bug 457062.

 (In reply to comment #12)
> Boris, what I've seen is that you have to upload at least two or three files at
> once. 

thats not true, see the steps to reproduce from comment #0 ..one file (10MB+) is enough to trigger the crash
Created attachment 340912 [details]
debug build apple crash report

Note: on the Debug Build you see :

###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().: 'mRawPtr != 0', file ../../dist/include/xpcom/nsCOMPtr.h, line 849
Break: at file ../../dist/include/xpcom/nsCOMPtr.h, line 849

before Firefox Crashs
Carsten, can you use gdb to get the stack? The Apple crash report doesn't contain line numbers as Boris has already mentioned. Thanks.
Hardware: Macintosh → All
Carsten, thanks for actual steps to reproduce!  I'll see what I can dig up here.
Assignee: nobody → bzbarsky
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.18?
Flags: blocking1.8.1.18+
Created attachment 340967 [details]
Fairly small crashtest
Created attachment 340968 [details] [diff] [review]
Fix

We're basically running into bug 457746 here, so mChannel is null when it shouldn't be.  I have no idea why the website calls abort/send on a single XHR object in more or less a loop, but whatever.
Attachment #340968 - Flags: superreview?(jonas)
Attachment #340968 - Flags: review?(jonas)
Gah.  This is actually just bug 390219 (which is in fact a regression from the bug that we backported to branch).  Why don't we take that more complete patch instead?
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 390219
Attachment #340968 - Attachment is obsolete: true
Attachment #340968 - Flags: superreview?(jonas)
Attachment #340968 - Flags: review?(jonas)
Fixed by landing of the patch in bug 390219.
Keywords: fixed1.8.1.18
I just tried to repro this with 2.0.0.17 on both Windows XP and OS X and I can upload with the basic uploader without any crash. Did something change on the site? Can anyone still reproduce the problem?
After talking to Sam, I tried this with a 10+ MB file (15 MB) and still had no crash. This was on OS X.
(In reply to comment #21)
> I just tried to repro this with 2.0.0.17 on both Windows XP and OS X and I can
> upload with the basic uploader without any crash. Did something change on the
> site? Can anyone still reproduce the problem?

Possibly; I believe comments in related bugs sounded like Gecko got in this crash-condition because of sites doing stupid things, so MediaFire may have been able to fix their code to not do stupid things faster than we can turn around a Gecko release ;)

To support that theory, I've just checked with Camino 1.6.4, and I got 25%/several minutes through a 15 MB upload with no problem, whereas last month it would reliably crash a few seconds into the upload.

OTOH, Boris's crashtest in comment 17 still crashes 1.6.4 but does not crash the latest Camino 1.6.5pre nightly, so you could potentially use that if you're looking for a verification testcase.
(Reporter)

Comment 24

9 years ago
MediaFire still crashes for me. I don't think anything has changed too much. Tested with Firefox 2.0.0.17 and Camino 1.6.4 and with two files uploading.
(In reply to comment #24)
> MediaFire still crashes for me. I don't think anything has changed too much.
> Tested with Firefox 2.0.0.17 and Camino 1.6.4 and with two files uploading.

Can you please provide a crash report? You can find it by typing "about:crashes" into the location bar. Thanks.
(In reply to comment #25)
> (In reply to comment #24)
> > MediaFire still crashes for me. I don't think anything has changed too much.
> > Tested with Firefox 2.0.0.17 and Camino 1.6.4 and with two files uploading.
> 
> Can you please provide a crash report? You can find it by typing
> "about:crashes" into the location bar. Thanks.
That doesn't work on the Gecko 1.8.1 branch.

the crash in comment 24 is probably the same as the ones that led to the creation of this bug...  those reports are already attached.

I don't crash with Fx 2.0.0.17 and Camino 1.6.4, although with Camino, I get an error: ERROR: Invalid key state, no status, after uploading, during the verification process.
(In reply to comment #24)
> MediaFire still crashes for me. I don't think anything has changed too much.
> Tested with Firefox 2.0.0.17 and Camino 1.6.4 and with two files uploading.

Since it still crashes for you, can you try the same steps with a nightly 1.8 build? You can get it at ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla1.8/. If it doesn't crash there, then we have gotten it fixed for 2.0.0.18.
(Reporter)

Comment 28

9 years ago
Yesterday's nightly of Firefox 2.0.0.18pre does not crash for me.
Seems to be fixed.
Thanks for the note. I'll mark this as verified since it isn't crashing for either of us.
Keywords: fixed1.8.1.18 → verified1.8.1.18
Crash Signature: [@ nsXMLHttpRequest::ConvertBodyToText]
You need to log in before you can comment on or make changes to this bug.