176040 - plugtmp directory not clearing contents until after plugin is unloaded

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Matthew Tippett]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

[serge (gone)]

>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

Comment 3

[Matthew Tippett]

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.

Comment 4

[Matthew Tippett]

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

[serge (gone)]

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?

Comment 6

[Matthew Tippett]

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.)

Comment 7

[Boris Zbarsky [:bzbarsky]]

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?

Comment 8

[Matthew Tippett]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> 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...

Comment 10

[Matthew Tippett]

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.

Comment 11

[Matthew Tippett]

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

[serge (gone)]

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

[serge (gone)]

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

[rubydoo123]

off to serge

Comment 15

[Matthew Tippett]

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

[serge (gone)]

>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

[Alexander Opitz]

Reporter can you reproduce this bug with a newer build (1.4 final)?
If not, then please close this bug as worksforme. Thanks.

Comment 18

[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 19

[Jochen Dausacker]

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

[Jochen Dausacker]

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

[Benjamin Smedberg]

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).