257048 - crash if profiles partition become out of space

Status: RESOLVED WORKSFORME

(Core Graveyard :: Profile: BackEnd, defect)

Description

[Valerio Messina]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; it-IT; rv:1.7.2) Gecko/20040803
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; it-IT; rv:1.7.2) Gecko/20040803

If the partition that contains profile become out of space, Mozilla crash simply
browsing, because it try to fill the cache in:
<letter>:\Documents and Settings\<osAccount>\Dati applicazioni\M
ozilla\Profiles\<mozProfile>\<randomString>.slt\Cache\Cache"
Other Win32 program report an "out of disk space error" but dont crash.


Reproducible: Always
Steps to Reproduce:
1.Leave 40MB of disk space in profile partition
2.Clear cache, and set to a default value of 50 MB
3.Browse for a while

Actual Results:  
Mozilla browser crash when the free space become low about than 18KB.


Expected Results:  
Give an error message that "low space on profile partition. Free some space and
retry operation".


TalkBack doesnt start.

P.S. I keep Win2K OS user account (Documents and Settings) on a different
partition than OS system partition like in many Unix.
But I think that problem happen also if only Mozilla profile is in a out of
space partition.

Comment 1

[OstGote!]

Should be better in 1.8 builds. See Bug 246675 and Bug 228978.

Comment 2

[Thomas Bertels]

A similar thing happens in Firefox 1.0 : when the disk is empty and I try to
launch Firefox, it craches in the same way.
Just before this to happen, I clicked on "clear cache". Firefox crashed whithout
error message when I tried to launch it again (and until I found the problem and
free up some space).

Comment 3

[Thomas Bertels]

I forget to recommend setting the product id to "Core"

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Valerio Messina]

As the automated resolve message, I try to reproduce the bug in 1.7.12
It crash similar to 1.7.2
When free space come under 0.3KB, sometimes browsing, free space increase in
10-20KB block and then continue to decrese. These are lost profile piece.
When free space become 0, Mozilla doesn't crash immediately, it continue for
some pages to render correctly.
But if you open the preference dialog or a heavy page, it crash for sure.
Bug 228978 speak about a Mozilla startup check and warn the user.
Even more if you check the free space only on Mozilla start, you cannot protect,
for example a 100MB free space, all allocated to Mozilla Cache.
Try to immagine to clear the cache, close Mozilla. Next days restart Mozilla,
the 228978 check pass with a lot of free space, than browse for a while, the
100MB fill up, Mozilla crash.
For me, every write to the disk (cache or config files) should check for free
space before, in realtime.

Comment 6

[Thomas Bertels]

(In reply to comment #5)
You have to try it with a newer version of gecko, this seems to be fixed in
gecko 1.8b4.
For seamonkey (ex-mozilla suite), see http://www.mozilla.org/projects/seamonkey/

Comment 7

[u63580]

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

Comment 8

[Thomas Bertels]

I'm going to mark this bug as invalid, since it doesn't reproduce anymore.

Comment 9

[Valerio Messina]

(In reply to comment #8)
> I'm going to mark this bug as invalid, since it doesn't reproduce anymore.
mark as fixed if it is fixed.
What mean invalid, that the bug wasn't real?

I'll try to reproduce it on Seamonkey 1.0.1, and I'll post a feedback.
thanks for now.

Comment 10

[Thomas Bertels]

(In reply to comment #9)
> (In reply to comment #8)
> > I'm going to mark this bug as invalid, since it doesn't reproduce anymore.
> mark as fixed if it is fixed.
> What mean invalid, that the bug wasn't real?
> 
> I'll try to reproduce it on Seamonkey 1.0.1, and I'll post a feedback.
> thanks for now.
> 
Actually, since there was no patch, this bug cannot be marked as fixed.
So there are three solutions: mark it as invalid, worksforme or duplicate of an other bug. I didn't find such a similar bug, but if you find one, just tell it here.

Comment 11

[Wayne Mery (:wsmwk)]

You tried a newer version UNDER THE SAME CONDITIONS (i.e. you did force it out of space when you retested, right?) and it worked, then it is reasonable to assume something fixed it, so WORKSFORME is appropriate.

INVALID = cause was not a bug (user error, etc), or cause was not in mozilla code, etc.

WORKSFORME = it works now, and didn't work before, and I don't know what fixed it.

Comment 12

[Valerio Messina]

this evening I tried the Seamonkey 1.0.7 leaving only 100KB on the profiles partitions, and browsing a while, taking care of the free spaces.
When the space come to 0 Bytes, the cache files stop growing, but NO crash happen!
Strangely no error or warning messages appear, but surely no crash.
Good Work.