I'm seeing 100% reproducible leakage of file descriptors to the following files every single time I load, for example, homestarrunner.com (I assume any page with flash content will do): /Library/Internet Plug-Ins/Flash Player.plugin/Contents/Resources/Flash Player.rsrc /Library/Internet Plug-Ins/Flash Player.plugin/Contents/Resources/English.lproj/Localized.rsrc I see it with trunk, 1.6a1pre, 1.5.1, 1.5, and even 1.0.6. Surprisingly, Firefox 2.0.0.3 and 2.0.0.7 don't have the problem on the same machine. I'm filing UNCO since it's certainly possible that this is a bug in the Flash beta (I'm running 9.0 r60), but if so we really need to make sure Adobe knows it happens, since it seems to be Camino-specific. It wouldn't surprise me at all if this is what's happening to all the other people reporting that Camino just dies eventually (especially since a forum poster with that problem had a lot of leaked Flash refs). I don't think I have any machines not running the flash beta anymore, so it would be helpful if someone without it could check for this behavior (reload homestarrunner.com 10 or 15 times, then run 'lsof | grep Camino' and see how many times the files above come up).

Nevermind about not being able to repro with Firefox; that was stupid user error. Firefox 2.0.0.7 and Minefield from a couple of days ago have the same behavior. Moving to core, and since core may be new to this issue, the symptom here is that after, say, surfing around YouTube for a while, Camino or Firefox will run out of available file descriptors, and lose the ability to do pretty much everything.

I installed 9.0 r28 and 9.0 r47. They both exhibit the same problem (although r28 doesn't have/leak the Localized.rsrc file).

Requesting blocking1.9, as well as blocking1.8.1.8 to get it on the radar.

This is somewhat more complex than I thought. I can generally reproduce the following: 1) Reload (or just browse around) homestarrunner.com for a while, until a lot of copies of the files are showing up in lsof. 2) Go to a non-flash page in that window. At this point, most of the flash file descriptors will vanish 3) Go back to homestarrunner.com in that window, and see that it suddenly jumps all the way up to the level it was at before. Step 2) doesn't always clean up what's there though, so at least sometimes the leak appears to be persistent.

As far as I can tell, if you close the tab that had the Flash in it, the leaked Flash Player.rsrc copies aren't getting cleaned up, either (Flash 9.0r47 and 2007092000 1.6a1pre, 10.3.9). FWIW, I also wasn't able to reproduce Comment 4 Step 2 doing any clean-up in a couple of tries, but I haven't tried extensively.

Thank you for the heads up. The Flash Player team will investigate.

Is this something Gecko could even do something about? Is it the Gecko plugin code or Flash itself doing the leaking? Although it would be great to have this fixed, it's not realistically going to block the 1.8.1.8 security update.

(In reply to comment #7) > Is it the Gecko plugin code or Flash itself doing the leaking? We don't know yet.

For what it's worth, we have observed that QuickTime is also leaking. And, we see that Firefox closes the Flash resources when it goes to page without Flash content.

I would guess that you are seeing the same thing I saw in comment 4 though, and that once you go back to a page with Flash content they will suddenly all be re-opened.

Yes, Stuart, that's what we see.

(In reply to comment #9) > For what it's worth, we have observed that QuickTime is also leaking. Do you have repro steps? If I continuously reload one of the trailers on Apple's trailer site, I never see more than one copy of its rsrc file, and if I browse away and come back I don't see re-opening of |n| copies of the resource file.

(In reply to comment #4) > 2) Go to a non-flash page in that window. At this point, most of the flash file > descriptors will vanish After a long time down a debugging rat-hole, I discovered that this isn't actually true, just (apparently) an artifact of lsof in some way (probably an lsof bug). I instrumented Camino to periodically walk all 256 file descriptors and check to see if they were open, and at the point where most of the duplicates vanish from lsof, the list of valid descriptors still includes every one of them. So it looks like it's just a plain leak, and lsof was confusing the issue.

This sounds like a flash bug, not a browser bug.

Michelle, have you all been able to make any determination about whether or not this is a Flash bug? My experiments like those mentioned in comment 12 suggest that it is, but I of course can't confirm it directly.

I am running into this myself, Camino locks up when it hits 255 open fd's with "lsof" listing most of them as being the 2 Flash Player related files. But here's a slight twist - having previously seen it, I then tried to invoke Camino from the command line, after first having done "limit descriptors unlimited". That bumped descriptors up from 256 to 10240. After doing that I opened it via "open /Applications/Camino.app". Shouldn't Camino have picked up the fd limit change? It apparently did not, because it just locked up on me again - with "lsof" reporting 256 fd's.

How to change the file descriptor limit for a process on OS X isn't within the scope of this bug; that would be more appropriate for a forum.

Any update from the Adobe side? Confirmation one way or the other as to whether or not this is a Flash bug would be very helpful, as this is a very serious problem for us, and if it's something that needs to be fixed in Mozilla code we really need to start looking into it as soon as possible.

Sorry, no real update from the Adobe side. We suspect it is a browser issue but we aren't yet certain. I don't know when we will have time for full investigation of this issue. Note that we see QuickTime and several components in the CarbonFramework leaking file descriptors as well.

(In reply to comment #20) > Note that we see QuickTime and several components in the CarbonFramework > leaking file descriptors as well. If you have repro cases, that would be helpful; again, I haven't been able to reproduce Quicktime .rsrc leaks in my tests, whereas I can render Camino or Firefox completely incapable of ever opening another file simply by reloading *any* page containing Flash content enough times.

For the QuickTime leaking descriptors, I think we tried homestarrunner.com, but it seems that we can see QuickTime .rsrc files without going to a specfic QuickTime site. To see the leak, we ran command "lsof | grep QuickTime".

blocking1.9+ since we don't know who's fault this is for sure but it very well could be ours and we need to investigate further. It is pretty serious and we can't ignore it just because there is some possibility that it is Flash's problem.

Since a number of people have been CC'd since my original comment explaining the effects of this bug, and most of the discussion has been about debugging, I want to make sure the user-effect of this bug (and why I marked it critical) is very clear: Mac Firefox and Camino will become unusable once n (where n is in the vicinity of 100-1500) pages containing Flash have been loaded since the last quit-and-relaunch, because it will not be able to open any files. This can manifest itself to users in a variety of ways: - no new pages will load, or the main page will load without any of the supporting resources - UI elements that haven't already had their graphics loaded won't render (e.g., If I repro this without ever opened tabs, then open tabs, there is no tab graphic, no close button graphic, etc.) - opening and saving files will fail - in my Firefox testing, even Quit stops working, and it has to be force quit. So far as I have been able to determine, the only possible way for users to avoid this situation is to quit and relaunch before they hit enough Flash-containing sites. For some users (who quit regularly, and don't visit a lot of sites with Flash), it will never happen. Others will see it after spending a few hours on YouTube, or playing Flash games, or any number of other things. I'm aware that this bug has no duplicates, but I don't think that's a useful indication of the frequency with which users hit this. Unless a user has significant technical knowledge and is very, very lucky (i.e., runs lsof at the time of the problem), the report would just say something like "After I use {Firefox,Camino} for a while, everything stops working until I quit". They would probably never guess that it was linked to Flash content, the debugging would go down lots of blind alleys, and the bug would probably eventually be closed or rot as unactionable. The only reason I found this was that we accidentally created a highly reproducible file descriptor leak in Camino, so suddenly the symptoms became very common, and the resulting discussions in forums ("hey, I have that problem too!") brought out users who had this problem rather than the Camino bug (which we discovered only after fixing the Camino bug didn't fix everyone). Several of those users thought that Camino was just unstable and had largely stopped using it, but still visited the forums from time to time. I strongly suspect that this issues is responsible for a significant amount of general noise in bugzilla, blog comments, user software reviews, etc. to the effect that {Firefox (for the Mac),Camino} is unstable/buggy/"just stops working".

(In reply to comment #22) > For the QuickTime leaking descriptors, I think we tried homestarrunner.com, but > it seems that we can see QuickTime .rsrc files without going to a specfic > QuickTime site. To see the leak, we ran command "lsof | grep QuickTime". And when you do that, you see an unbounded number of QuickTime .rsrc file descriptors over time? I never see more than two or three, no matter how many pages with QT content I visit. I'm not familiar with the plugin loading code internals enough to be sure, but I assume that having one copy of all the plugins' rsrc files always open is expected--at worst it's an extremely minor issue. The critical issue is continuously leaking more and more of them over time, every single time Flash is loaded. I have not been able to reproduce that behavior with any other plugin.

Thanks for all the additional information. We are taking a closer look at this now and should be able to provide an update from what we see on our end shortly.

We've confirmed this is a Flash Player bug and we will fix it in an upcoming release. Thank so much for your help, again, and our apologies! When the fix is in public beta, I will post a note to this bug so you may test it if you wish.

Fantastic, thanks for the investigation!

If this is indeed a Flash Player bug, shouldn't it be seen with every extant Mac Web browser? (I've only personally run into it with Camino myself. Yes, I did notice that Stuart claimed he's seen it with Firefox as well.) Anyway, hope Michelle's right, very troublesome bug, have run into it quite often, will be nice to see it fixed.

Safari does not have the leak problem since it does not open the resource map again when reloading a Flash page.

(In reply to comment #29) > If this is indeed a Flash Player bug, shouldn't it be seen with every extant > Mac Web browser? (I've only personally run into it with Camino myself. Yes, I > did notice that Stuart claimed he's seen it with Firefox as well.) Please adhere to the bugzilla etiquette guidelines when commenting in bugs; baselessly questioning the basic competence (or truthfulness; I can't tell which you are doubting) of both a representative of the maker of the plugin in question and a respected contributor who has spent many hours debugging this issue without any justification does not constitute a productive comment. Given comment 27, there is no need for additional discussion here about the cause of this bug.

Regarding comment #29 and comment #31: For future reference, it is completely legitimate to ask why, if a bug is deemed a Flash Player bug, why that bug doesn't appear in all browsers. In this case, the answer is in comment #30. On the Flash Player team we investigate how different browsers behave to determine whether the bug is ours or not. In any case, this bug should be taken care of now. Thanks all!

Can we figure out why we're reopening the resource map multiple times and stop doing that? That would let us fix users of earlier Flash versions too, right? Michelle, if you happen to have a stack or something that would indicate what Gecko code is causing that to happen, it would be much appreciated.

This bug is now fixed in the Flash Player 10 beta: http://labs.adobe.com/downloads/flashplayer10.html

INVALID per the whiteboard now that there's a released version of Flash (namely, all 10.x versions) that contains the fix for this.

People will still hit this until Apple pushes a new version of Flash through software update... This should at least be mentioned in the FAQ

(In reply to comment #38) > People will still hit this until Apple pushes a new version of Flash through > software update... This should at least be mentioned in the FAQ Apple actually did this, amazingly, in 10.5.7 (see bug 494762 comment 3), so that portion of the userbase running 10.5.7 should have a version of Flash with fixes for this bug.

I filed bug 496344 on comment 30 and comment 33. I'm sorry I missed doing that when the comments were made; I sorta wish someone had caught that. :(