plugtmp directory not clearing contents until after plugin is unloaded

RESOLVED WORKSFORME

Status

()

Core
Plug-ins
P3
major
RESOLVED WORKSFORME
16 years ago
6 years ago

People

(Reporter: Matthew Tippett, Unassigned)

Tracking

Trunk
mozilla1.4beta
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PL2:NA], URL)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020913 Debian/1.1-1

When using mozilla with Flash MX, the plugtmp directory fills up with images
that are getting continually loaded by the 

Reproducible: Always

Steps to Reproduce:
Will follow shortly with a URL.

Load the URL, look at /tmp/plugtmp
Actual Results:  
Directory fills up with images that have been loaded a large number of times.

Expected Results:  
After the use of a data file is complete, the file should disappear.

On any MX page that continually loads a large amount of data, the plugtmp
directory will
eventually fill up.

nsPluginStreamListenerPeer::SetupPluginCacheFile(nsIChannel* channel)

Seems to be the code that at least creates it.
Well.. the problem is that we have no way of knowing that the plugin is done
with the data file, do we?

We can't even unlink it once the plugin has it open, because it may rely on
being able to close and reopen it, unless the API explicitly prohibits that.

Comment 2

16 years ago
>After the use of a data file is complete, the file should disappear
that is true, but how do we know e.g. some audio plugin finishes playing the
stream from file? and user does not want to repeat that stream again?
-->INVALID
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 3

16 years ago
I am fine with repeated requests having a given footprint.  The problem is that
we have an embedded style system that needs to be able to stay on the page with
the flash running for days (if not weeks or months on end).  If the same URL is
loaded it probably shouldn't avoid the file and write a new one.

I understand about keeping some files around, but with the URI, it shouldn't
just skip the file.
(Reporter)

Comment 4

16 years ago
Serge, please wait for the sample swf to be uploaded.  This will affect all
platforms and affects long term stability of the product.

The swf should be uploaded within 10-15 minutes.

Comment 5

16 years ago
Matthew, IFAIK flash plugin does not require file extension so it could be
perfectly serve from mozilla disk or memory cache.
Why your system is requiring flash stream from the file?
(Reporter)

Comment 6

16 years ago
The url as part of this bug (Note Flash 6 or Flash MX only)

http://www.technology-forum.org/load_pic.swf

Is fairly simple, it loads every second the same image from the server (it could
easily be a webcam image - in fact in our product it is a web cam image).

Under Linux, you will see the /tmp/plugtmp directory fill up very quickly, under
Windows, I assume that a similar directory is created.

(BTW, by observation of what gets created where, I would hazard a guess that
there may be a link following into some obscure file somewhere there.)
Wait.  So the _plugin_ downloads images?  And sticks them in its "current
working directory" which happens to be plugtmp?  How exactly is Mozilla supposed
to delete them if it doesn't even know they exist?
(Reporter)

Comment 8

16 years ago
No,

It is using the flash plugin under Mozilla.  The flash movie is downloading and
displaying the images in-situ.  The flash doesn't care what the underlying
system does.

In nsPluginStreamListenerPeer::SetupPluginCacheFile(nsIChannel* channel) the
channel is written to a file in the plugtmp directory.   The logic for all the
behaviour is in that file.

So recapping, 
   o The flash movie is simply doing a 'loadMovie("hitch.jpg")' every second.
   o The flash plugin is working within the plugin API provided by mozilla
   o Mozilla creates in some instances the /tmp/plugtmp directory
   o Mozilla creates the files as they are refered
   o if Mozilla detects a name clash, Mozilla renames the file and records it
   o when the movie is unloaded, Mozilla cleans up
   o if the movie is not unloaded in time, Mozilla will fill up the filesystem
and crash the system.

Mozilla (and the method described above) is doing all the work.

Two ways forward, (from an abstract development point of view)
   o Determine if changing the filename actually does anything otherwise re-use
the same filename
   o Ensure that if the plugin API releases/destroys or whatever the file it is
cleaned up immeadiately.


> In nsPluginStreamListenerPeer::SetupPluginCacheFile(nsIChannel* channel) the

This writes the actual flash content (just the swf) to the plugtmp dir.

> The flash movie is simply doing a 'loadMovie("hitch.jpg")' every second.

I assume loadMovie() is a function exposed by the flash plugin itself to flash
code that it runs?

I'm reopening the bug, since I don't know whether the plugin API allows a plugin
to ask Mozilla to load a file off the network and put it somewhere or whether
the plugin must do its own network access...
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 10

16 years ago
Flash uses a scripting language called ActionScript.

loadMovie() is an actionscript command that loads an external movie (JPG or SWF)
into a frame for display.

Under flash there is no clear distinction between a JPG or a SWF.  Judging by
the mode (777) that the files are being created, I would say it is indeed in the
method indicated, in particular the following lines for *ALL* the content loaded.  

    // Yes, make it unique.
    rv = pluginTmp->CreateUnique(nsIFile::NORMAL_FILE_TYPE, 0777); 
    if (NS_FAILED(rv)) return rv;

If there is an easy way for me to provide the list of plugin API calls that are
being made, I am more than willing to assist in the resolution of this.
(Reporter)

Comment 11

16 years ago
Just a word of thanks to all the people who have responded so quickly to this.

I think it may have been the fastest NEW/INVALID/UNCOFIRMED bug cycle in history.

Comment 12

16 years ago
hmm, on test case url I hit |nsPluginStreamListenerPeer::SetupPluginCacheFile|
call if browser cash is not available.
did you set your disk cash size == 0?

Comment 13

16 years ago
actually to properly destroy the stream plugin can call |NPN_DestroyStream|
http://developer.netscape.com/docs/manuals/communicator/plugin/pgfn2.htm#1007441
in which case all resources allocated by the stream suppose to be freed.

Comment 14

16 years ago
off to serge
Assignee: beppe → serge
Priority: -- → P3
Whiteboard: [PL2:NA]
Target Milestone: --- → mozilla1.4beta
(Reporter)

Comment 15

16 years ago
Just tried 1.2b, it doesn't seem to occur with that, note that there is now a
public beta for flash.  This isn't affecting me anymore.

There is still a problem with the mozilla process growing without bounds on a
similar file.  I will be looking for deeper at it.  Is there any easy way to
determine if memory has been allocated within Mozilla vs within the plugin?

Matt

Comment 16

16 years ago
>if memory has been allocated within Mozilla vs within the plugin?
no, there is no easy way to do such kind of determination:(

Comment 17

15 years ago
Reporter can you reproduce this bug with a newer build (1.4 final)?
If not, then please close this bug as worksforme. Thanks.
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/
Assignee: srgchrpv → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: shrir → plugins

Comment 19

11 years ago
I remember exactly the same Problem with my Version of Firefox. (2.0.0.11)

I wrote a scheduled Task, that deletes all Items once a hour, but the Directory explodes if you got a lot of Tabs and Windows open.
I registered up to 50 Items per second with 6 Windows and 34 Tabs.
I deleted over 500 000 Files in 10 Directories. 
The Browser listed after every startup a new Folder with a Number attached.

here is the Batch-File i wrote for deleting the Files every hour.

cd C:\Dokumente und Einstellungen\Administrator\Lokale Einstellungen\Temp\plugtmp\
echo j|del *.*

this is the english-Language Version:

cd c:\documents and settings\administrator\local settings\tmp\plugtmp\
echo j|del *.*

Comment 20

11 years ago
Sorry, i mentioned that the Number of Windows and Tabs does´nt effect this problem.

It is only the one URL: http://www.kmg-fernmeldebau.de/

Comment 21

6 years ago
I am 99% sure that we now delete temporary files requested by plugins using NP_ASFILE or NP_ASFILEONLY as soon as that instance is destroyed (not the plugin).
Status: NEW → RESOLVED
Last Resolved: 16 years ago6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.