Last Comment Bug 195637 - using StreamAsFile cannot always find disk file (cache deletes file larger than disk cache)
: using StreamAsFile cannot always find disk file (cache deletes file larger th...
Status: NEW
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 Linux
: P3 normal with 2 votes (vote)
: Future
Assigned To: Peter Lubczynski
:
: Benjamin Smedberg [:bsmedberg]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-02 08:38 PST by tenthumbs
Modified: 2009-08-23 12:11 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description tenthumbs 2003-03-02 08:38:55 PST
I found this on Linux using plugger but it doesn't seem limited to plugger.

If a plugin uses StreamAsFIle _and_ the file is larger than the disk cache 
limit, then the cache deletes the file before the plugin can use it. The plugin 
just has a path to a non-existent file.

I thought this was a known problem but I couldn't find another bug on it. If
it's a dup, sorry for the spam.
Comment 1 Peter Lubczynski 2003-03-03 11:48:14 PST
do you have a testcase?
Comment 2 Andrew Schultz 2003-03-03 17:58:01 PST
> do you have a testcase?

set disk cache size to 50KB and try to load any avi/mpg (via http), etc that
plugger is configured to handle.

if disk cache is disabled or set to 0 KB, Mozilla puts the file in /tmp/plugtmp/
Comment 3 tenthumbs 2003-03-04 03:47:47 PST
> do you have a testcase?

You can also leave the cache at the default 50MB and just transfer via 
http a file larger than that. It happens with plugger and large audio 
files but can occur with any mime type. I can see the file being stored 
in the cache directory and its name is handled to the plugin but the 
cache deletes the file before the plugin can open it.
Comment 4 Peter Lubczynski 2003-03-04 10:14:44 PST
Plugin code can do the caching itself as is done in the /tmp case. 

I wonder if there is a way to tell if the request will fit in the cache?
Comment 5 Darin Fisher 2003-03-04 10:49:20 PST
hmm... yuck.  this is a difficult problem to solve.  HTTP downloads only
sometimes include a Content-Length header, so often times you don't know the
length of a data stream.  perhaps the right solution is to set a flag so that
the hard limit on the cache can be temporarily exceeded.  the large file marked
with this flag would not have to displace other files, and we could delete it as
soon as possible.  i can't think of any other way to deal with this problem.
Comment 6 WD 2004-01-05 14:15:40 PST
Is bug 229984 related to this?
The cache does grow to allow HTTP downloads of files larger than the cache's max
size, but once that occurs the disk cache can often be put in an unusable state.
Comment 7 Jan Kasprzak 2009-02-20 06:06:56 PST
Hello,

any updates wrt. this bug? I have just ran into it in the latest-greatest Fedora 10/x86_64, when downloading a large PDF file for opening. Apparently, mozplugger-helper deletes the file and then runs evince (my PDF viewer) with a nonexistent file as an argument:

$ ps ax|grep moz
32106 ?        Ss     0:00 mozplugger-helper 1304,1,10,98566154,0,0,1422,996 evince "$file"
32107 ?        Sl     0:00 evince /home/kas/.galeon/mozilla/galeon/Cache/8B4AB048d01
$ ls -l /home/kas/.galeon/mozilla/galeon/Cache/8B4AB048d01
ls: cannot access /home/kas/.galeon/mozilla/galeon/Cache/8B4AB048d01: No such file or directory

I have found that when the same file is downloaded via https+basic authentication, it is displayed correctly (the file is downloaded into /tmp/plugintmp/plugin-<origfilename>.pdf, which is a security hole tracked by bug #164842, but at least it opens the file).

My software is: Fedora 10/x86_64, xulrunner-1.9.0.6-1.fc10.x86_64, firefox-3.0.6-1.fc10.x86_64 (the bug is also present in other gecko-based btowsers such as galeon-2.0.7-5.fc10.x86_64).

Note You need to log in before you can comment on or make changes to this bug.