Closed
Bug 457411
Opened 16 years ago
Closed 16 years ago
[1.8 branch] Crash while uploading files to MediaFire.com [@ nsXMLHttpRequest::ConvertBodyToText]
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 390219
People
(Reporter: r.mozley, Assigned: bzbarsky)
References
()
Details
(Keywords: crash, regression, verified1.8.1.18)
Crash Data
Attachments
(5 files, 1 obsolete file)
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•16 years ago
|
Version: unspecified → 2.0 Branch
Comment 1•16 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.
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•16 years ago
|
||
Reporter | ||
Comment 3•16 years ago
|
||
Reporter | ||
Comment 4•16 years ago
|
||
Comment 5•16 years ago
|
||
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
Comment 6•16 years ago
|
||
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?
Comment 8•16 years ago
|
||
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.
Assignee | ||
Comment 10•16 years ago
|
||
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.)
Comment 12•16 years ago
|
||
(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?
Comment 13•16 years ago
|
||
(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
Comment 14•16 years ago
|
||
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
Comment 15•16 years ago
|
||
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
Assignee | ||
Comment 16•16 years ago
|
||
Carsten, thanks for actual steps to reproduce! I'll see what I can dig up here.
Updated•16 years ago
|
Assignee: nobody → bzbarsky
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.18?
Flags: blocking1.8.1.18+
Assignee | ||
Comment 17•16 years ago
|
||
Assignee | ||
Comment 18•16 years ago
|
||
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)
Assignee | ||
Comment 19•16 years ago
|
||
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
Closed: 16 years ago
Resolution: --- → DUPLICATE
Assignee | ||
Updated•16 years ago
|
Attachment #340968 -
Attachment is obsolete: true
Attachment #340968 -
Flags: superreview?(jonas)
Attachment #340968 -
Flags: review?(jonas)
Assignee | ||
Comment 20•16 years ago
|
||
Fixed by landing of the patch in bug 390219.
Keywords: fixed1.8.1.18
Comment 21•16 years ago
|
||
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?
Comment 22•16 years ago
|
||
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•16 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.
Comment 25•16 years ago
|
||
(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.
Comment 26•16 years ago
|
||
(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.
Comment 27•16 years ago
|
||
(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•16 years ago
|
||
Yesterday's nightly of Firefox 2.0.0.18pre does not crash for me. Seems to be fixed.
Comment 29•16 years ago
|
||
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
Updated•13 years ago
|
Crash Signature: [@ nsXMLHttpRequest::ConvertBodyToText]
You need to log in
before you can comment on or make changes to this bug.
Description
•