Closed
Bug 613915
Opened 14 years ago
Closed 13 years ago
[OOPP] Not enough storage is available to process this command [async plugins regression] (copy/paste broken)
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(blocking2.0 betaN+)
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: fehe, Assigned: jimm)
References
()
Details
(4 keywords, Whiteboard: See comment #5 [hardblocker])
Attachments
(4 files)
Since the November 11 build, I've been routinely losing certain functionality and also getting the message "Not enough storage is available to process this command," when either trying to access bookmarks in the sidebar or download a file. When the problem occurs, I cannot do either of the following until I restart the browser: 1. copy and paste (copy option is available in context menu, but all paste options remain grayed out) 2. Launch a web shortcut by either double-clicking or drag-dropping 3. Access any bookmark items (get "Not enough storage is available to process this command") 4. Download any file (also get "Not enough storage is available to process this command") I've tried, without success, to find an STR. However, I've noticed the following pattern: 1. It typically happens sometime after I have watched one or more TV shows via a site's flash-based player (during which time I'm doing some additional surfing). 2. Since enabling Flashblock, the problem occurs less frequently. This leads me to suspect that this might have something to do with bug 596451; however, I have no way of verifying this. Here is the Nov 10 to Nov 11 pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=df1d1ff6b489&tochange=0f17e5f1eb01 Does anyone have any idea what may be happening here? Under what conditions would Gecko normally encounter the "Not enough storage is available to process this command" error? Is it Windows that's generating that error message? If so, is this a malloc or compartments bug?
By the way, the title of the error dialog, displaying the above message, is "GetLastError"
Comment 2•14 years ago
|
||
That error is produces by Windows, not us. How full is your hard drive?
I have a 1 TB HD (35 GB free on system partition) and 4 GB of RAM (Firefox would have been consuming less than 600 MB at the time -- yes Fx memory consumption, since compartments, has been atrocious) This is a regression since between Nov 10 and 11 nightlies. I never experienced this before -- even on my older computer, which was much slower and had much less memory and storage).
Just encountered this again, when trying to save a download. This time, I got this error in Error Console. Because copy/paste was broken, I had to type it out by hand: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIHelperAppLauncher.saveToDisk]" nsresult:"0x80004005(NS_ERROR_FAILURE)" location:"JS frame :: jar:file:///C:/Program%20Files/Internet/firefox/omnijar!/components/nsHelperAppDlg.js :: <TOP_LEVEL> :: line 473" data: no] jar:file:///C:/Program%20Files/Internet/firefox/omnijar!/components/nsHelperAppDlg.js Also, this time I did not get the "Not enough storage is available to process this command" error. I'm now wondering if this is somehow related to DOM Storage, as I use the BetterPrivacy extension, and I have it configured to "Auto-delete DOMStorage file." I also have it configured to "Delete Flash cookies by timer." If so, this would explain the Flash angle, by why would it affect downloading or copy/paste? And why is it Windows and not Firefox that's giving the "Not enough storage is available to process this command" error? Surely this must be in response to Firefox requesting result status from the Windows API. Even so, this worked for months prior to the breakage, so it's difficult to say for sure that it is as a result of BetterPrivacy deleting things -- although, I realize Gecko's API is not stable and things break. In a further attempt to identify the cause, I'm now disabling the "Delete Flash cookies by timer" option, to see if I still encounter the issue. If so, I'll disable the "Auto-delete DOMStorage file" option, subsequently disabling the extension altogether.
This bug requires windowless flash to reproduce. A major change affecting plugins (within the regression windows) is bug 596451. Therefore this is the likely cause, as it regressed after it landed (Nov 11 nightly) and does not happen if IPC plugins is disabled. Since bug 596451 is in effect only when IPC plugins is enabled, it very much has to be the cause. STR (using Flash Player 10.2b1 on XP Pro): 1. Create a shortcut to any website on your desktop 2. Launch Minefield with a new profile 3. Double-click the shortcut to verify that it does indeed open the link 4. Close the tab and instead visit: http://www.citytv.com/vancouver/show/micro/80864--fringe 5. Scroll down till you see the "MORE EPISODES" list. 6. Click one of the episodes (as of this writing, "Entrada" and "The Abducted..." are the listed episodes) 7. Allow the video to play, ads and all, until it is about 80 % or more complete 8. Double-click that shortcut you placed on the desktop earlier. It should fail to open. 9. At this point, you will also be unable to download files, copy/paste to any textarea, or drag-drop any web shortcut to anywhere on the Firefox interface. Some time later tonight or tomorrow, I'll see if I can also reproduce this using an XP VM in VirtualBox -- so as to possibly eliminate any potential hardware-related factors.
Blocks: 596451
blocking2.0: --- → ?
Component: General → Plug-ins
Keywords: helpwanted,
qawanted,
regressionwindow-wanted
QA Contact: general → plugins
Whiteboard: See comment #5
(In reply to comment #5) > Some time later tonight or tomorrow, I'll see if I can also reproduce this > using an XP VM in VirtualBox -- so as to possibly eliminate any potential > hardware-related factors. Successfully reproduced using XP Pro in a VirtualBox 3.2.12 r68302 VM (with Guest Additions 3.2.12), using Flash Player 10.1.102.64; therefore, pretty much anyone should be able to reproduce this.
Keywords: reproducible
Summary: Not enough storage is available to process this command → [OOPP] Not enough storage is available to process this command [async plugins regression]
Comment 7•13 years ago
|
||
I'd like to figure out more about what's going on, perhaps stacks at the time the dialog is presented.
Assignee | ||
Comment 8•13 years ago
|
||
Hmm, everything I've found on the net indicates this a resource starvation problem on the system. http://technet.microsoft.com/en-us/library/cc978735.aspx Have you tried cleaning up your drive? Right click on your system drive, select drive cleanup.
Assignee | ||
Comment 9•13 years ago
|
||
You might also try disabling hardware acceleration in the advanced prefs panel to see if that helps.
Comment 10•13 years ago
|
||
Jim, can you see if we're holding lots of handles open, or leaking handles, or something?
Assignee | ||
Comment 11•13 years ago
|
||
(In reply to comment #10) > Jim, can you see if we're holding lots of handles open, or leaking handles, or > something? Don't appear to be. User and GDI objects as well as Handles are constant.
Assignee | ||
Comment 12•13 years ago
|
||
I'll run things through AQTime tomorrow looking for resource allocation problems, but I'm not seeing anything obvious at this point.
Reporter | ||
Comment 13•13 years ago
|
||
(In reply to comment #9) > You might also try disabling hardware acceleration in the advanced prefs panel > to see if that helps. It has nothing to do with hardware acceleration. It occurs even though I have it disabled. As stated, in comment 6, this is easily reproducible in a Windows XP SP3 VirtualBox VM, so you can rule out anything to do with my hardware. I have more than enough system resources. It is reproducible even if the STR in comment 5 if performed either after a "real" system restart or after a VM start. You should be able to reproduce this, given that it is reproducible in a VirtualBox VM. (In reply to comment #7) > I'd like to figure out more about what's going on, perhaps stacks at the time > the dialog is presented. Tried long ago, but couldn't figure out how to get anything meaningful from it. Not being a programmer didn't help
Assignee | ||
Comment 14•13 years ago
|
||
What are the system resources set to in the VirtualBox VM? (I haven't used this, but in vmware you can specify memory and disk.) I understand this is easily reproducible for you, on your system, but it seems specific to your setup since we have no other reports of this problem. I'll try to setup an xp image in VirtualBox tomorrow to see if I can confirm.
Assignee | ||
Comment 15•13 years ago
|
||
Also, to rule out hardware problems, could you try testing a small set of builds prior to November 11th? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
Reporter | ||
Comment 16•13 years ago
|
||
(In reply to comment #14) > I understand this is easily reproducible for you, on your system, but it seems > specific to your setup since we have no other reports of this problem. Not true. See the following thread: http://forums.mozillazine.org/viewtopic.php?p=10191983#p10191983 http://forums.mozillazine.org/viewtopic.php?p=10192169#p10192169 http://forums.mozillazine.org/viewtopic.php?p=10193711#p10193711
Reporter | ||
Comment 17•13 years ago
|
||
(In reply to comment #15) > Also, to rule out hardware problems, could you try testing a small set of > builds prior to November 11th? > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ See comment 5. I already did regression testing and nailed the exact daily build. No need to retest. It is, without question, the Nov 11th build that has the regression. And as already stated, it is related to IPC plugins; thus, within the regression window, bug 596451 is the best candidate.
Assignee | ||
Comment 18•13 years ago
|
||
(In reply to comment #17) > (In reply to comment #15) > > Also, to rule out hardware problems, could you try testing a small set of > > builds prior to November 11th? > > > > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ > > See comment 5. I already did regression testing and nailed the exact daily > build. No need to retest. It is, without question, the Nov 11th build that > has the regression. And as already stated, it is related to IPC plugins; thus, > within the regression window, bug 596451 is the best candidate. Ok, so just to be sure, you've confirmed the regression window by running various nightlies around November 11th? I wasn't sure based on your comments you had tested various builds after experiencing this and confirmed this regressed on that date.
Reporter | ||
Comment 19•13 years ago
|
||
Hardware Specs: --------------- Motherboard: Asus M4A89GTD PRO USB 3 Memory: 4 GB DDR3 PC-12800 (G.SKILL Ripjaws) Processor: AMD Athlon II X4 630 (2.8 GHz) Graphics: Integrated Radeon HD 4200 (AMD 890GX chipset) Hard Drive: 1 TB WD10EARS OS: Windows XP PRO SP3 Graphics Driver: Catalyst 10.12 VM Specs (including Guest Additions): ------------------------------------- CPU Cores: 1 Memory: 384 MB Video Mem: 64 MB Storage: 10 GB OS: Windows XP PRO SP3 Bug is reproducible BOTH on REAL HARDWARE and on VM
Reporter | ||
Comment 20•13 years ago
|
||
(In reply to comment #18) > Ok, so just to be sure, you've confirmed the regression window by running > various nightlies around November 11th? Correct. No builds prior to Nov 11th have the regression.
Assignee | ||
Comment 21•13 years ago
|
||
Hmm, bsmedberg, this looks suspect - http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginInstanceChild.cpp#2735 Is that handle getting closed? Also, why do we repeatedly share this with the parent?
Reporter | ||
Comment 22•13 years ago
|
||
If further proof is needed that this has nothing to do with my hardware, I just reproduced this in on my work laptop using Windows XP Mode. Laptop Hardware Specs: ---------------------- Platform: Dell Vostro 3500 Memory: 4 GB DDR3 Processor: Intel Core i3 350M 2.26 GHz Dual Core w/HyperThreading Graphics: Intel HD ? (Havendale/Clarkdale chipset) Hard Drive: 320 GB Seagate OS: Windows 7 PRO 64-bit Windows XP Mode Specs: ---------------------- Memory: 256 MB Video Mem: ? Storage 350 GB Differencing OS: Windows XP PRO SP3
Assignee | ||
Comment 23•13 years ago
|
||
(In reply to comment #22) > If further proof is needed that this has nothing to do with my hardware, I just > reproduced this in on my work laptop using Windows XP Mode. > > Laptop Hardware Specs: > ---------------------- > Platform: Dell Vostro 3500 > Memory: 4 GB DDR3 > Processor: Intel Core i3 350M 2.26 GHz Dual Core w/HyperThreading > Graphics: Intel HD ? (Havendale/Clarkdale chipset) > Hard Drive: 320 GB Seagate > OS: Windows 7 PRO 64-bit > > Windows XP Mode Specs: > ---------------------- > Memory: 256 MB > Video Mem: ? > Storage 350 GB Differencing > OS: Windows XP PRO SP3 Is using "Windows XP Mode" a required factor in reproducing this on this system, or can you get it to happen on Win7 without this?
Assignee | ||
Updated•13 years ago
|
Reporter | ||
Comment 24•13 years ago
|
||
(In reply to comment #23) > Is using "Windows XP Mode" a required factor in reproducing this on this > system, or can you get it to happen on Win7 without this? I believe this bug affects only Windows XP, as I so far have not reproduced it on Windows 7; and this likely explains why there aren't a whole lot of reports (most of the Minefield crowd are using Windows 7). I'm sure there will be more reports (or at least confusion, bitching and moaning) one beta 8 hits the masses.
Comment 25•13 years ago
|
||
(In reply to comment #21) > Hmm, bsmedberg, this looks suspect - That handle is valid only in the chrome process, and should be adopted/closed by SharedDIBWin::Attach when it is received: http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginInstanceParent.cpp#518 We don't cache it because caching is hard when dealing with plugin size changes. Is this D3D9-only, or perhaps even D3D9-not-ex only? If hardware acceleration is disabled, does this still happen?
Updated•13 years ago
|
Summary: [OOPP] Not enough storage is available to process this command [async plugins regression] → [OOPP] Not enough storage is available to process this command [async plugins regression] (copy/paste broken)
Reporter | ||
Comment 26•13 years ago
|
||
(In reply to comment #25) > Is this D3D9-only, or perhaps even D3D9-not-ex only? If hardware acceleration > is disabled, does this still happen? It doesn't matter whether hardware acceleration is enabled or disabled. It even doesn't matter whether run on real hardware or VM.
Assignee | ||
Comment 27•13 years ago
|
||
(In reply to comment #25) > (In reply to comment #21) > > Hmm, bsmedberg, this looks suspect - > > That handle is valid only in the chrome process, and should be adopted/closed > by SharedDIBWin::Attach when it is received: > http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginInstanceParent.cpp#518 Hmm, handles and objects are stable on XP as well. Unless something is leaking out here that process explorer isn't picking up, it doesn't appear to be a resource leak.
Assignee | ||
Comment 28•13 years ago
|
||
UI, have you tried reproducing this in safe mode? http://support.mozilla.com/en-US/kb/Safe%20Mode You can also enter safe mode by holding down shift and launching a new instance of fx.
Assignee | ||
Comment 29•13 years ago
|
||
Does anyone have any trouble getting this video to play? http://video.citytv.com/video/detail/704674349001.000000/Marionette/ I've tried both ipc enabled/disabled with no success.
Assignee | ||
Comment 30•13 years ago
|
||
Iu, another thing you can try: 1) install process explorer http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx 2) run that, in view, select "select columns" 3) under Process Memory, add user and gdi objects 4) under process performance, add handle count then run the video you see this on and look for leaks in these objects for plugin container and firefox.
Reporter | ||
Comment 31•13 years ago
|
||
(In reply to comment #28) > UI, have you tried reproducing this in safe mode? Safe mode shouldn't matter, as this is reproducible with a new profile.
Reporter | ||
Comment 32•13 years ago
|
||
(In reply to comment #29) > Does anyone have any trouble getting this video to play? > > http://video.citytv.com/video/detail/704674349001.000000/Marionette/ > > I've tried both ipc enabled/disabled with no success. If you weren't adblocking, it might be that it's blocked for your region. The bug is also reproducible with long, ad-riddled videos at cbsnews.com. Visit www.cbsnews.com and try with any of the full episode versions of 60 minutes or 48 hours mysteries (see top-most links on that page). Make sure you're not blocking the ads somehow. (In reply to comment #30) > Iu, another thing you can try: > I'll take a look later tonight
Reporter | ||
Comment 33•13 years ago
|
||
Here are the Process Explorer results. I captured them at three different times, as indicated in the attached CSV.
Reporter | ||
Comment 34•13 years ago
|
||
By the way, you should (in theory) be able to reproduce this bug with any windows flash version of a typical hour-long-running TV show available on the net (preferably one that also has ad interruptions). So, anything accessible from wherever you are, and meeting all the stated criteria, should allow this bug to manifest, once the video has progressed far enough (80 - 100 % or so). DO NOT, however, minimize the window where the flash video is being played. It seems Firefox does something differently, if the window is minimized, and the bug does not show up.
Assignee | ||
Comment 35•13 years ago
|
||
(In reply to comment #33) > Created attachment 498947 [details] > Process Explorer results > > Here are the Process Explorer results. I captured them at three different > times, as indicated in the attached CSV. Thanks IU. Over what time period do you see that handle number for the container climb?
Reporter | ||
Comment 36•13 years ago
|
||
(In reply to comment #35) > Thanks IU. Over what time period do you see that handle number for the > container climb? It was about 30 min
Reporter | ||
Comment 38•13 years ago
|
||
For anyone needing an additional site/video for triggering this bug, note that this is also reproducible with full episodes at www.aetv.com (should be accessible for both Canada and US), using steps in comment 5. You might also be able to reproduce with full episodes at www.history.com; however, I haven't tried those yet.
Comment 39•13 years ago
|
||
I don't believe this problem requires Flash, though that may be the most convenient way to reproduce the problem. I get this problem (Not enough storage is available to process this command) 100% of the time with Firefox 4.0b8 when I try to copy and paste text from another thread or the URL in the address bar into a post in the MozillaZine forums, and Firefox is the only application running. The only tabs are the two forum threads, there are no other Firefox windows, flashblock is enabled, and none of the web sites visited displayed flash. The only caveat is that it requires me to have been using Firefox for a couple of hours and most of the page file to have been used. I'm using a PC that is obviously running out of memory - it frequently does a lot of swapping if I switch between Firefox 4.0b8 and Thunderbird 3.1.7 (with no other applications running) for example. Its a 446MB XP SP3 1.7GHz Celeron Toshiba Satellite A105 laptop with a 700MB page file. Firefox peaks at 270MB (disk cache is disabled and permanent private browsing mode is used). Copy and paste works fine in other applications. I did NOT have this problem with Firefox 4.0b7, even when running Word, Excel, Firefox, Thunderbird and Windows Explorer at the same time (which is rather painful) for most of the day.
Reporter | ||
Comment 40•13 years ago
|
||
(In reply to comment #39) > I don't believe this problem requires Flash, though that may be the most > convenient way to reproduce the problem. Maybe; maybe not. However, it is related to the plugin system. If you set dom.ipc.plugins.enabled to false, you will not experience this bug. Also, it should have nothing to do with any limitations of your physical hardware, as it occurs here with a system having 4 GB of RAM, a 6 GB paging file, and many more Gigabytes of HD space to spare. Firefox usually locks up and crashes when it runs out of memory. That is not the case here. The browser remains usable, with the exception of certain data interchange-related operations.
Assignee | ||
Comment 41•13 years ago
|
||
(In reply to comment #40) > (In reply to comment #39) > > I don't believe this problem requires Flash, though that may be the most > > convenient way to reproduce the problem. > > Maybe; maybe not. However, it is related to the plugin system. If you set > dom.ipc.plugins.enabled to false, you will not experience this bug. Eric, would you mind trying this to confirm? We need as many data points we can get.
Reporter | ||
Comment 42•13 years ago
|
||
Jim: At one point I was suspicious of bug 606976, because it dealt with memory; however, I dismissed it because it seemed not to fit somehow -- especially since I experienced it only with windowless flash. If anyone has hourlies for November 10 to early November 11, please let me know. I would like to verify whether I fingered the right bug or not. Thanks.
Comment 43•13 years ago
|
||
I can produce try server builds for any intermediate changeset for you to test. Just give me the last known good revision and the first known bad revision.
Reporter | ||
Comment 44•13 years ago
|
||
(In reply to comment #43) > I can produce try server builds for any intermediate changeset for you to test. > Just give me the last known good revision and the first known bad revision. Thanks, but unfortunately, I need hourlies first; otherwise, I can't be more specific. If someone can provide me with Nov 10 to early Nov 11 hourlies, I'll narrow it down.
I don't see the m-c builds for the 10th and 11th, but the debug builds for those days span from 9623c2032948 (Nov10) to 0f17e5f1eb01 (Nov11).
Reporter | ||
Comment 46•13 years ago
|
||
Timothy: Alternately, you could create one tryserver build without bug 606976 and one without bug 596451, and I'll see if either doesn't have the bug. (In reply to comment #45) > I don't see the m-c builds for the 10th and 11th, but the debug builds for > those days span from 9623c2032948 (Nov10) to 0f17e5f1eb01 (Nov11). The is not with what day it regressed. I know for a fact that it was the Nov 11 nightly. What I'm trying to find out is the specific hourly build. But as for the debug builds, of all the times I've asked, no one has ever answered and explained to me how to get those binaries working on Windows.
Reporter | ||
Comment 47•13 years ago
|
||
Argh! That should have read: The question is not what day it regressed...
Looking at the pushlog, 9623c2032948 is a few pushes before 212a391d3b79, which is right before bug 596451 (async plugin painting) landed, and bdbef533364f is the final merge in that bug landing. Bug 606976 landed in the middle of the async painting push, at cset da433c7320ab. Cset right before that was f7b85d9a0900, right after was 94324cad0457.
Comment 49•13 years ago
|
||
I don't know if it makes sense to try changesets in the middle of the bug 596451 merge or not. So lets first determine that its bug 596451 for sure. A try server build for mozilla-central rev bdbef533364f (the bug 596451 merge, any only test changes since the nov 10 nightly) will appear in a few hours at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-3b78f6b80341
Reporter | ||
Comment 50•13 years ago
|
||
(In reply to comment #49) > A try server build for mozilla-central rev bdbef533364f (the bug 596451 merge, > any only test changes since the nov 10 nightly) will appear in a few hours at > http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/tnikkel@gmail.com-3b78f6b80341 Thanks, Timothy. I have confirmed that this try server build has the regression. Am I understanding you correctly that the try server build is Nov 10 nightly + bug 596451?
Comment 51•13 years ago
|
||
It is exactly what you would get if you had an hourly for mozilla-central rev bdbef533364f. There are only 3 changes in rev bdbef533364f that weren't in the nov 10 nightly according to your pushlog from comment 0. Two were test only, and the other is bug 596451.
Reporter | ||
Comment 52•13 years ago
|
||
Thanks. That confirms it then. What's next?
Comment 53•13 years ago
|
||
I'm not sure, someone more familiar with bug 596451 can determine what should be done.
Reporter | ||
Comment 54•13 years ago
|
||
Disclaimer: I'm not a programmer. I've been perusing the patches in bug 596451 and taking specific interest in the "shared-memory" kong fu, so I decided to do a little googling for "shared memory" + "not enough storage is available to process" Here is some are some interesting finds that might prove helpful: http://stackoverflow.com/questions/2770424/does-net-use-device-dependent-or-device-independent-bitmaps http://stackoverflow.com/questions/2418776/createdibsection-leaving-not-enough-storage-error-but-seems-to-still-work-anyw The second link seems to finger these patches: Part D - async painting on Windows (opaque), rev. 1 Part E - Implement transparency, rev. 1.2 and maybe also: Part J - Fix testplugin alpha painting, rev. 1 Also, take a look at this comment to an original poster's question (regarding the same type of error), on a different forum. This too seems to finger Part D, E, and J: http://www.gamedev.net/community/forums/topic.asp?topic_id=573436&whichpage=1� Thus, I suspect the problem lies with one of those patches.
Comment 55•13 years ago
|
||
Per comment 41 I set dom.ipc.plugins.enabled to false and retested. The problem doesn't reoccur.
Assignee | ||
Comment 56•13 years ago
|
||
This is dump of open handles in my vmware image. The number never seems to change while viewing video, but I am curious why there are usually three open. I wonder if on systems that experience this we are experiencing some sort of ipc message loss, causing handle leaks. (I'm pretty sure we would report such a failure in some way, but I might be wrong about that.) Still searching for an answer here, if anyone who can reproduce this knows a bit about working with windbg, please post here and I'll walk you through generating reports like this.
Comment 57•13 years ago
|
||
Those are OS handles, right? I wonder if we're leaking GDI handles, but not OS handles.
Assignee | ||
Comment 58•13 years ago
|
||
(In reply to comment #57) > Those are OS handles, right? I wonder if we're leaking GDI handles, but not OS > handles. Those are shared memory handles, and the three were due to three instances of flash (two ads, one video). I'm planning on checking other handle types here as well. But preliminary data from process explorer indicate we aren't leaking gdi objects either. Maybe windbg will find something pe is missing.
Reporter | ||
Comment 59•13 years ago
|
||
Jim, If you're still unable to reproduce this, I suspect you might be doing one or more of the following no-no's: (1) You are hiding or covering the video window; (2) You are not allowing the video to play long enough; (3) You are not playing windowless flash videos; (4) You are using 64-bit Windows XP SP3. Re #1: The flash video MUST NOT be minimized or completely covered. I discovered that minimizing the browser window with the flash video prevented the bug from occurring. I suspect this has something to do with either Windows or Firefox not painting hidden content. Re #2: You MUST ALLOW sufficient playback time for the windowless flash video(s). I have discovered that the issue contributing to the bug is cumulative. That is, it does not need to be one long continuous video, but the cumulative time is important. Either playback AT LEAST 40 minutes of one video or a cumulative of a bunch of videos. With 60 minutes of playback, you should definitely hit this. Re #3: The flash videos MUST BE windowless. Sites like youtube will not work. Re #4: Make sure you're using 32-bit Windows XP SP3 If you've met all the above conditions, launching a web shortcut from your desktop (provided that Firefox is the default application) should fail and you will experience this bug.
Reporter | ||
Comment 60•13 years ago
|
||
By the way, just to be sure about reproducibility, I tried on a WinXP system at work and the bug was easily reproduced. So, if someone says they can't reproduce this, on a Windows XP system, it would be nice to have details of what it is they were doing.
Assignee | ||
Comment 61•13 years ago
|
||
(In reply to comment #60) > By the way, just to be sure about reproducibility, I tried on a WinXP system at > work and the bug was easily reproduced. So, if someone says they can't > reproduce this, on a Windows XP system, it would be nice to have details of > what it is they were doing. Just confirming.. I'm currently using 48 hours shows to try and reproduce - http://www.cbsnews.com/sections/48hours/main3410.shtml For example: http://www.cbsnews.com/video/watch/?id=7160067n&tag=cbsnewsMainColumnArea.0 Do these videos exhibit the problem for you Iu?
Reporter | ||
Comment 62•13 years ago
|
||
(In reply to comment #61) > Just confirming.. I'm currently using 48 hours shows to try and reproduce - > > http://www.cbsnews.com/sections/48hours/main3410.shtml > > For example: > > http://www.cbsnews.com/video/watch/?id=7160067n&tag=cbsnewsMainColumnArea.0 > > Do these videos exhibit the problem for you Iu? I'm able to reproduce with that link, using a physical Win XP PC at work. I was unsuccessful with XP mode on my work laptop, possibly because I have to background it, but who knows (can't double-check now).
Comment 63•13 years ago
|
||
This bug has come up as one of the highest-ranking issues for feedback from beta 8, so if we need to take a mini or snag a desktop machine from the QA lab in order to reproduce it, let's do that.
Comment 64•13 years ago
|
||
aakash, does input give you enough data to confirm that these reports are Windows XP only?
Reporter | ||
Comment 65•13 years ago
|
||
Funny thing with the XP mode is: I left Desperate Housewives (http://watch.ctv.ca/#clip395956) backgrounded and subsequently went for lunch. When I got back, I noticed the bug had occurred.
Updated•13 years ago
|
Whiteboard: See comment #5 → See comment #5 [hardblocker]
Comment 66•13 years ago
|
||
Just encountered this bug in: 4.0b8 Cannot Copy any text to clipboard from Firefox (Ex: Copy this text, paste it onto Notepad = nothing gets posted) Cannot Paste any text to Firefox from other apps & Firefox (Ex: Copy this text, try pasting it in this input window = following error: GetLastError Not enough storage is available to process this command.) NB: Error message appears twice. I've had a YouTube video in one of the tabs for around 5 hours. Running Windows XP, SP3. - Niri
Comment 67•13 years ago
|
||
Also noticed that "PRINT" option is not working. File > Print.. = No response CTRL + P = No response (Print working fine with other applications) Further, I'd like to add that with the Copy scenario, previously copied text in clipboard is lost. (i.e. * Copy some text from Notepad * Copy text from Firefox * Paste onto Notepad = Nothing gets posted)
Comment 68•13 years ago
|
||
[Sorry for the spam!] Now, FILE DOWNLOAD is not working. From this page, I tried to view the attachments (Process explorer results) STEPS: 1. Left-click on the Process explorer results link 2. Select "Open with Microsoft Office Excel" (Issue 1) 3. After (Issue 1) occurs, dismiss by pressing Ok (Issue 2) 4. After (Issue 2) occurs, dismiss by pressing Ok and close Downloads tab 5. Left-click on the same link again 6. Select "Save File" (Issue 3) Result: Issue 1: Following error message: "C:\Docue~1\PC\LOCALS~1\Temp\process_explorer_result-1.csv There is not enough free memory to run this program. Quit one or more programs, and then try again." Issue 2: Error message: "C:\....csv could not be opened, because an unknown error occurred. Try saving to disk first and then opening the file." Issue 3: No response. Download does not start. No error message displayed. I tried closing all instances of MS Excel, same issue observed. Since many major functionalities are failing, I'm going to Exit and Re-launch Firefox. I've saved a screenshot of "Troubleshooting Information" screen as copy-paste was not working. Let me know if it's needed at all.
Reporter | ||
Comment 69•13 years ago
|
||
@Niri: All of that is already known. See comment 0.
Assignee | ||
Comment 70•13 years ago
|
||
The one difference in Niri experience was that it was possibly caused by YouTube, which is windowed vs. every other example here being windowless. Niri, were you watching a YouTube clip on the YouTube site, or was the YouTube video embedded in some other site? Can you provide a link to what you were watching possibly?
Comment 71•13 years ago
|
||
Jim, I was watching this YouTube video, on YouTube website (not embedded) => watch?v=e444UivnXco Firefox was probably running since the day b8 was installed, and had not been exited. And it's very much possible I'd previously viewed videos from other websites also, including those embedded in Facebook. But this particular issue occurred while watching the above video; it was loaded around 5 hours ago, and wasn't closed.
Assignee | ||
Comment 72•13 years ago
|
||
I've been able to reproduce the copy paste problem (48 Hours video run for 22 minutes). I haven't reproduced some of the errors people are seeing, or the handle run up Iu experienced, but I'm hoping if I track down the copy paste problem, it'll also fix the rest of the issues. Fingers crossed.
Comment 73•13 years ago
|
||
Bug 331878 Comment 3 mentiones running Fx with non-admin/limited Privileges when the "getlasterror: not enough storage is available to access this command" Message shows up. Maybe that can be a Trigger, too?
Reporter | ||
Comment 75•13 years ago
|
||
(In reply to comment #72) > I haven't reproduced some of the errors people are seeing... Two scenarios, amongst others, where you can get the "Not enough storage..." error message are: when you try to drag-and-drop text on a textarea; and when you right-click a bookmark in the bookmarks sidebar. For example (once the bug is in effect): 1. Visit http://www.google.com/firefox 2. Highlight any non-hyperlinked word in the sentence "Be part of shaping Firefox 4." 4. Drag-and-drop the highlighted word on the in-page search textarea. 5. You should get two consecutive (the second after you dismiss the first) "GetLastError" popups with the message "Not enough storage is available to process this command." I'm assuming you can reproduce the downloading and drag-dropping of shortcuts issues, as those seem hard to miss. It might be worth looking at my comment 54, if you haven't already. It may be helpful to your investigation.
Reporter | ||
Comment 76•13 years ago
|
||
(In reply to comment #73) > Bug 331878 Comment 3 mentiones running Fx with non-admin/limited Privileges > when the "getlasterror: not enough storage is available to access this command" > Message shows up. Maybe that can be a Trigger, too? The author explicitly states that he had not tried with an admin account. And, furthermore, since the author is running 4beta8 and says, "This only seems to happen after the browser has been running for a long time," I see nothing new there.
Comment 77•13 years ago
|
||
IU when this bug is in effect, if you kill the plugin-container.exe do the effects go away? (i.e. can you copy/paste or drag-n-drop again?)
Assignee | ||
Comment 78•13 years ago
|
||
(In reply to comment #77) > IU when this bug is in effect, if you kill the plugin-container.exe do the > effects go away? (i.e. can you copy/paste or drag-n-drop again?) In the case where I was able to reproduce, navigating away from the flash page so that all instances were destroyed had no effect. I don't remember if I killed the pc process though. Might be interesting to test. My guess is this won't fix the problem, the memory problems show up in firefox.exe where api calls made by that process (for example clipboard com calls in widget) fail with out of memory errors.
Reporter | ||
Comment 79•13 years ago
|
||
(In reply to comment #77) > IU when this bug is in effect, if you kill the plugin-container.exe do the > effects go away? (i.e. can you copy/paste or drag-n-drop again?) No. Just checked.
Comment 80•13 years ago
|
||
Hmm that's interesting.. The big number of handles from the .csv that IU posted is being held by plugin-container. If killing it doesn't solve the problem it might not be a leak of OS handles..
Assignee | ||
Comment 81•13 years ago
|
||
(In reply to comment #80) > Hmm that's interesting.. The big number of handles from the .csv that IU posted > is being held by plugin-container. If killing it doesn't solve the problem it > might not be a leak of OS handles.. I've not had any luck reproducing the handle run up. But I can reproduce the out of memory error failure in the parent.
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Comment 82•13 years ago
|
||
The other odd thing is this only exists in XP, which makes me wonder if we are tripping over some sort of an os bug or quirk that has been fixed in future versions. Worst case if we don't figure this out, we can document it with a good test case and open an msdn support ticket.
Comment 83•13 years ago
|
||
By all measures, regular memory is not being leaked.. unless the tools are failing miserably to track that. What can be seem is a very large number of page faults.. the page file or the memory map is either too committed or fragmented and most likely CreateDIBSection is failing because of that. CreateDIBSection is used in both problematic places (copy-paste, drag-n-drop) so that's very suspicious.. I reproduced this in Windows XP Mode on Win7, after running the video for 38 minutes. See screenshot of some data after the bug was in effect. And the big drop in PF is about 10sec after I closed the browser.
Comment 84•13 years ago
|
||
PFs per second when video is played: 10k ~ 15k with windowed flash (youtube), beta7 or dom.ipc.enabled=false it's stable and close to 0 I don't know what this means yet, just posting the data I found so far.
Comment 86•13 years ago
|
||
So far vmmap has not demonstrated any data out of the ordinary. Here's a snapshot after the bug was in effect.
Is it possible to use xperf to get stack traces for the page faults?
Comment 88•13 years ago
|
||
Great idea. Yes it is. After fiddling with the parameters, here's the command I used to generate the stack traces above: xperf -on all_faults+latency -stackwalk profile+HardFault+PagefaultTransition+PagefaultDemandZero+Pagefau ltCopyOnWrite+PagefaultGuard+PagefaultHard+PagefaultAV After 1min sampling the significant numbers reported were for PagefaultTransition and PagefaultDemandZero. Then I sorted by PagefaultTransition and grabbed the part that looks more relevant from the firefox.exe process: https://spreadsheets.google.com/ccc?key=0AlK0-BfJNaypdGEzRlhmU0RvZmVLUzBmdzdFcERBRXc&hl=en
I guess we should be recycling buffers instead of doing a lot of memory allocation and freeing?
Comment 90•13 years ago
|
||
although the call to CreateDIBSection with shMem->handle() reuses the buffer (If I understood it right), and the big number of transitions could be just the parent and child process swapping the front/back buffers? (seems like pagefault transitions are generated when a page is accessed from a different process) Maybe it's not the cause of the problem after all..
In light of http://stackoverflow.com/questions/2418776/createdibsection-leaving-not-enough-storage-error-but-seems-to-still-work-anyw, can you try inserting a call to SetLastError(0) after a successful call to ::CreateDIBSection?
Comment 92•13 years ago
|
||
FTR, when trying to copy+paste, the popup that appears with the GetLastError message is this: http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsClipboard.cpp?mark=299-300,315-316#316 At least once when I reproduced this the message said "The operation completed successfully" instead of the "not enough storage.."
Comment 93•13 years ago
|
||
(In reply to comment #91) > In light of > http://stackoverflow.com/questions/2418776/createdibsection-leaving-not-enough-storage-error-but-seems-to-still-work-anyw, > can you try inserting a call to SetLastError(0) after a successful call to > ::CreateDIBSection? SetLastError(0) didn't help. When the clipboard fails, the following call to IDataObject->GetData returns S_OK, but stm.hGlobal is left with 0x0. http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsClipboard.cpp#391
(In reply to comment #93) > (In reply to comment #91) > > In light of > > http://stackoverflow.com/questions/2418776/createdibsection-leaving-not-enough-storage-error-but-seems-to-still-work-anyw, > > can you try inserting a call to SetLastError(0) after a successful call to > > ::CreateDIBSection? > > SetLastError(0) didn't help. Did you put it after *all* our calls to ::CreateDIBSection?
Comment 95•13 years ago
|
||
I did not, only on the one at SharedDIBWin.cpp.. I don't think the other ones are being hit during my test (except for the cairo one, maybe it is..). I'll add to the others and check again
Comment 96•13 years ago
|
||
One time that I reproduced it I've managed to get into a situation where instead of arbitrarly not working, IDataObject->GetData was returning E_OUTOFMEMORY. I suspected it could be http://support.microsoft.com/kb/126962 : "out of memory messages even with plenty of memory and page file available, due to desktop heap being depleted" However I've used dheapmom (http://www.microsoft.com/downloads/en/details.aspx?familyid=5cfc9b74-97aa-4510-b4b9-b2dc98c8ed8b&displaylang=en) to watch it and the numbers are steady and around 8% of desktop heap usage.
Reporter | ||
Comment 97•13 years ago
|
||
What about looking into what's causing all the page faults mentioned in comment 84? That seems like a good place to start.
Reporter | ||
Comment 98•13 years ago
|
||
Never mind. Didn't read bug 625425 before posting. :-)
Comment 99•13 years ago
|
||
Seems to be pretty common, a number of reports on Input (XP users exclusively, it seems) that have problems with copy/paste: https://input.mozilla.com/en-US/search/?product=firefox&q=paste
Comment 101•13 years ago
|
||
Noticed the bug in Beta 8. Still exists in Beta 9. Running Windows XP SP3 on dual-core laptop with 2 GB RAM & plenty of free hard drive space. As a "power user", I often have 50+ tabs open at a time and often watch Hulu and other video services on my laptop, but not sure what triggers the bug. Copy & Paste function dies in browser with previously reported error message. OS continues to function normally (allowing copy & paste between other windows -- just not Firefox). Hardware and OS are stable with plenty of resources available in RAM and CPU %... restart of Firefox to re-open all open tab resolves issue temporarily... until something else triggers same bug. Seems clear that this is a FF bug and while it may be restricted to Windows XP 32 bit, it does not appear to be hardware dependent.
Comment 102•13 years ago
|
||
I had an interesting experience that may or may not be related — where the copy command didn't work when triggering the shortcut or main Edit menu, but the copy operation in the *context* menu worked. This was on OS X, though — so might be unrelated.
Comment 103•13 years ago
|
||
(nightly build, for the record)
Assignee | ||
Comment 104•13 years ago
|
||
fixed by bug 625425
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 105•13 years ago
|
||
Verified fixed Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110128 Firefox/4.0b11pre Thanks
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 106•13 years ago
|
||
(In reply to comment #105) > Verified fixed > Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110128 Firefox/4.0b11pre > > Thanks Thank you for all the help!
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•