When saving a file under either Linux (i386 Debian 2.2) or Solaris (sparc 7), I get crashes if the file would take me over my disk quota for the disk the file is being saved to. This happens with the latest nightly builds for Linux (8/29/00) and Solaris (8/09/00). Under either of the 2 OSs, a dialog box pops up that says "Unknown error". On Solaris, mozilla segfaults immediately after the dialog pops up. On Linux the segfault does not happen happen until I hit OK on the "Unknown error" dialog box. On Linux the following error message prints to the terminal window just before the crash: JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x8 0520010 [nsIStreamTransferOperation.Stop]" nsresult: "0x80520010 (<unknown>)" location: "JS frame :: chrome://global/content/downloadProgress.js :: onUnload : : line 124" data: no] The disk with the quota is an NFS disk being served by a Solaris 7 box.

Hmm..this wouldn't surprise me if it was happening, given the lax diskspace checking that we do in other situations. Unfortunately, I can't confirm this bug right now, because I don't save over remote file systems.

tever, would this belong to you/networking. if so, am not sure who the engr should be. law, would this be your realm? (guessing since you were the last to touch downloadProgress.js.)

I checked further and this crash does occur if saving a file directly to a disk that has a quota on it (avoiding NFS altogether): quota_ufs: over hard disk limit (pid 10646, uid 620, inum 786193, fs /mydisks/user_a) WEBSHELL+ = 6 WEBSHELL- = 5 JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80520010 [nsIStreamTransferOperation.Stop]" nsresult: "0x80520010 (<unknown>)" location: "JS frame :: chrome://global/content/downloadProgress.js :: onUnload :: line 124" data: no] This I tested only on Solaris. I also found that I got the same crash on Linux when I filled up a partition (no quotas involved). So this bug is broader than I first reported. I also tried to fill up a partition under Windows 95. There was no crash, but there was also no eror message. Mozilla happily saved enough of the file to take up all of the free disk space, and then continued as though there were no problems saving the file.

No crash here on Solaris 7 (SunOS 5.7) nightly 2000-08-30-10-M18. When going over quota (nfs partition) the files get silently truncated without any error message from mozilla (just the over quota message on the console).

Well, I still get this bug with build 2000083121 on Solaris 7 here. Crash still occurs when over quota on NFS mounted disk or on same disk accessed directly through UFS. Now crash doesn't occur until after "Unknown error [2 805200 10]" box is closed and that box contains reads. I removed my .mozilla directory, but that had no effect. I ran this crash under gdb and got the following: JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x8 0520010 [nsIStreamTransferOperation.Stop]" nsresult: "0x80520010 (<unknown>)" location: "JS frame :: chrome://global/content/downloadProgress.js :: onUnload : : line 124" data: no] WEBSHELL- = 4 Program received signal SIGSEGV, Segmentation fault. 0xfbe38424 in nsStreamXferOp::OnDataAvailable () from /net/aurora/a1/crumley/sun/moz2/package/components/libmozxfer.so (gdb) Any idea why this might happen to me, but not pmcq@emmenet.it? I haven't re-tested on Linux.

You are right, sorry. I confirm the same crash (Solaris). However if you fill the quota partition (for ex. with a cat /dev/zero>useless-file) then you download a file, you get a zero-length file saved without any error. (See similar bug 3129) If you keep some kbyte free on the quota partition, you download a bigger file on a "without quota" partition (I've done this by mistake), then you download again the same file on the quota partition, the file gets silently truncated without any error. These are the tests I've done tomorrow. As I'm unable to find anything similar in bugzilla, I change the state to NEW.

Adding crash keyword...

nav triage team: nsbeta3+, P2 since we don't know how hard it is to fix. Matt says we should just randomly erase shit :-)

*** Bug 20088 has been marked as a duplicate of this bug. ***

I'm also seeing this on Win2000, moving OS to All. Behaviour: When trying to save a file on a disk that's almost full, and saving the file would take up more than the available space, Mozilla will first happily try to download the file, until it actually has filled up the entire disk, then it comes up with a dialog saying "Unknown error 2 80520010". Pressing Ok will crash Mozilla. I have a Talkback incident on this, ID: TB17001423X

PDT agress P2 due to crash. Duplicate of bug 48620?

*** Bug 51884 has been marked as a duplicate of this bug. ***

I have two minor patches which avoid the crash. Waiting for Warren to OK the buffered streams one. Index: nsStreamXferOp.cpp =================================================================== RCS file: /cvsroot/mozilla/xpfe/components/xfer/src/nsStreamXferOp.cpp,v retrieving revision 1.32 diff -w -r1.32 nsStreamXferOp.cpp 330a331 > break; 333a335 > break; Index: base/src/nsBufferedStreams.cpp > =================================================================== > RCS file: /cvsroot/mozilla/netwerk/base/src/nsBufferedStreams.cpp,v > retrieving revision 1.8 > diff -r1.8 nsBufferedStreams.cpp > 335a336,339 > > if (!mStream) { > > // Stream already cancelled/flushed; probably because of error. > > return NS_OK; > > }

Bill, let's get this into RTM instead of beta 3. Have you got approval on that fix yet?

Nope. Now I need to submit under new rules and I'm working on that.

Changed to real "rtm need info" bug.

I attached this patch to bug 35161 to fix that bug and this one (and also bug 48620): http://bugzilla.mozilla.org/showattachment.cgi?attach_id=16135

Fix in hand

Making this a dup of 35161. The crash (and crappy message box) are due to the same problem(s) there.

*** This bug has been marked as a duplicate of 35161 ***

*** Bug 55214 has been marked as a duplicate of this bug. ***

verified dup