firefox crashed, when downloading an file on full hd

Bug #234661 reported by Christian Herzberg on 2008-05-24
2
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Confirmed
Critical
XULRunner
Confirmed
Critical
firefox (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: firefox-3.0

I tried to download a file to my download folder. Firefox crashed immediately without any Message. After restart a message announced that the download was aborted because of a full disk. Indead the diskspaces for the home-partition had been exhausted.
All my tabs had gone and no recreation of tabs befor crash was possible, as I expected (firefox2 would have ask me.)

This is Ubuntu 8.04
packge: firefox-3.0~b5+nobinonly-0ubuntu3
used Add-on: Download Statusbar 0.9.6.1

ProblemType: Bug
Architecture: i386
Date: Sat May 24 22:11:42 2008
DistroRelease: Ubuntu 8.04
Package: firefox-3.0 3.0~b5+nobinonly-0ubuntu3
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/lib/kde4/bin:/usr/lib/kde4/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-16-generic i686

In Most cases where these data losses occur it will be due to the Disk Cache
saving enough data during a session to bump the disk up to the full point, or to
the user downloading enough files to use remaining space.

The shut down routine should check for disk sapce and if it is full the disk
cache should be emptied to free up some space. This is also a data loss, but
cache loss is far less severe than losing bookmarks, passwords, etc. Emptying
the cache should prevent loss of critical data in most cases, the exception
being people who have set their disk cache to zero size.

> Emptying the cache should prevent loss of critical data in most cases,
> the exception being people who have set their disk cache to zero size.

Or people who have the cache and profile on a different disks (or partitions).

> Or people who have the cache and profile on a different disks (or partitions).

True, but the real cause of these bugs is poor management of disk resources on
the part of the user, and someone who has gone to the effort to set up Mozilla
profiles on seperate disks/partitions is unlikely to ignore disk management
after that.

There is a limit on what can be done to save a user from himself. A Warning of
low resources at startup will help, but if that warning is set at resources less
than 100 MB downloading a large file and expanding the disk cache by surfing
sites can trigger this problem with no warning. There will also be people who
ignore the warning. Dumping the cache if there are low resources at shutdown
will save most (NOT all) users from losing critical data and fit in with the
bandaid nature of this bug.

I'm only sugesting this approach for the 1.6 release. A Better fix for these
related bugs needs to be found before 1.7 is released.

In , Mvl (mvl) wrote :

Clearing the cache at shutdown doesn't work. Or not in itself.
For example, the cookperm.txt is written when there are changes. This means that
it isn't written at shutdown. So, if the last attempt to wirte failed due to no
disk space, and then at shutdown there suddenly is disk space, the file is still
not written to disk.
Afaik, the same goes for cookies. I don't know about others.

What aren't we putting up a message immediately with something like cookperm.txt?

"Unable to write cookperm.txt because the disk is full. Please free some place
and then click OK"

would have been a nice one to get, but it looks like no one is biting to do this
work. getting too late for 1.6. moving to 1.7

I still think its a good idea to warn users when we get near the danger zone at
startup... doesn't need a lot of precision or lots of anticipation of what the
user might be loading into the disk cache for the upcoming session...

that said we would still need to get someone one to whip up a patch...

need to minus for 1.7a since no patch has appeared

Is bug 236153 a duplicate

Ben

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

(In reply to comment #8)
> Is bug 236153 a duplicate
>
> Ben

No. That bug covers not being able to use Mozilla/Firefox at all because it
can't create a lock file. This bug covers
Mozilla/Firefox/<insert_gecko_browser_here> crashing because it can't write to
the cache file, therefore causing dataloss.

In , Asa (asa) wrote :

Neil, any chance you can help us out with something here?

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

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

Can you provide instructions as to how I can recover my saved email and news
preferences, and my saved email, after I have encountered the full disk problem?

I NEED to get back my record of saved email. I'm sure it's still sitting in
Mozilla's email database somewhere, but I don't know how to access it.

Michael, not only is there no work being done on this bug at the moment
(or at least none being recorded), but there been no substantive comment added to
it since December 2003.

You would be better off checking the FAQ and other troubleshooting resources
for the program that you are using (Thunderbird/MAS).

It seems that this bug is related to the Core product, isn't it ?

removing late-l10n since this on longer seems to be in any product release blocking paths

No comment in more that 1½ years, resetting A+QA.
Moz 1.7 has come and gone, resetting Target.

Christian Herzberg (chrisch) wrote :

Binary package hint: firefox-3.0

I tried to download a file to my download folder. Firefox crashed immediately without any Message. After restart a message announced that the download was aborted because of a full disk. Indead the diskspaces for the home-partition had been exhausted.
All my tabs had gone and no recreation of tabs befor crash was possible, as I expected (firefox2 would have ask me.)

This is Ubuntu 8.04
packge: firefox-3.0~b5+nobinonly-0ubuntu3
used Add-on: Download Statusbar 0.9.6.1

ProblemType: Bug
Architecture: i386
Date: Sat May 24 22:11:42 2008
DistroRelease: Ubuntu 8.04
Package: firefox-3.0 3.0~b5+nobinonly-0ubuntu3
PackageArchitecture: i386
ProcEnviron:
 PATH=/usr/lib/kde4/bin:/usr/lib/kde4/bin/:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.24-16-generic i686

Christian Herzberg (chrisch) wrote :
Nick Ellery (nick.ellery) wrote :

Hi, and thanks for reporting this bug.
Is this a one time occurence, or does this same crash happen every time you try to download these types of files?

Changed in firefox-3.0:
status: New → Incomplete
Christian Herzberg (chrisch) wrote :

The crash happend, when my home-partition was full. After that I deleted some old iso's and downloaded the files without any trouble.
I didn't try it again with full harddisk and had to download some gigabyte to get this situation again. So, for now it is a one time occurrence, but I think it's possible to happen again.
Regards

On Sun, May 25, 2008 at 10:39:09PM -0000, Christian Herzberg wrote:
> The crash happend, when my home-partition was full. After that I deleted some old iso's and downloaded the files without any trouble.
> I didn't try it again with full harddisk and had to download some gigabyte to get this situation again. So, for now it is a one time occurrence, but I think it's possible to happen again.
> Regards
>

 retitle "crash on download with full /home partition"

 affects ubuntu/firefox-3.0
 status triaged
 importance medium

 affects ubuntu/xulrunner-1.9
 status triaged
 importance medium

please test if this can be reproduced. and search for existing bugs in
bugzilla.mozilla.org

 affects firefox
 status incomplete
 affects xulrunner
 status incomplete

 - Alexander

Changed in firefox-3.0:
importance: Undecided → Medium
status: Incomplete → Triaged

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

Alexander Sack (asac) wrote :

https://bugzilla.mozilla.org/show_bug.cgi?id=228978 is the meta bug for full disk issues.

Changed in firefox:
importance: Undecided → Unknown
status: Incomplete → Unknown
Changed in xulrunner:
importance: Undecided → Unknown
status: Incomplete → Unknown
Changed in firefox:
status: Unknown → Confirmed
Changed in xulrunner:
status: Unknown → Confirmed
Changed in firefox:
importance: Unknown → Critical
Changed in xulrunner:
importance: Unknown → Critical
Adolfo Jayme (fitojb) on 2013-02-20
no longer affects: xulrunner-1.9 (Ubuntu)
affects: firefox-3.0 (Ubuntu) → firefox (Ubuntu)
Changed in firefox (Ubuntu):
importance: Medium → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.