Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.21 Safari/532.0 Build Identifier: I20080617-2000 I have a flash application that runs inside the eclipse internal browser view. Whenever it tries to allocate some amount of memory, it will crash the entire eclipse workbench. I tried to reproduce the problem just with the SWT browser widget, and the behaviors were the same. Reproducible: Always Steps to Reproduce: 1. Launch Eclipse in an empty workspace 2. Open the internal browser view 3. Point to the MemTest.html to launch the flash application 4. Every press on the button in the flash application will allocate approx. 10 mb of memory. 5. press on the button a few times until around 100 to 200 mb, then the crash will happen
Created attachment 147779 [details] html file that points to the flash app
Created attachment 147780 [details] Actual flash app
to SWT: is there an outlook for a fix or a possible work-around? Two different customers of our adopting product are hitting the same OOM problem in SWT browser.
I've been experimenting with the attached page and found the following so far (tried with eclipse/swt 3.4.2 and latest from the 3.6 stream): Config: Windows 2000 with IE6 and Flash Player 9 - stand-alone external IE 6: flash9.osx crashes at 1369M - small SWT snippet showing Browser: flash9.ocx crashes at 1245M - eclipse internal browser view: flash9.ocx crashes at 810M Config: Vista with IE8 and Flash Player 9 & 10 (both versions behaved similarly) - add 150M-200M to each of the Windows 2000 numbers, no other difference I haven't tried on an XP machine yet, but when I do I'm not expecting to see much difference. The stand-alone IE number shows the point at which the Flash player crashes with no swt/java involvement, and there's no way for swt to avert a crash that's happening in flash9.ocx. The SWT snippet case gets almost as high as the stand-alone IE case, and I think the difference is the overhead of having java+SWT loaded. I think the eclipse internal view case is similar, the difference is the overhead of having java+eclipse loaded. The swt/eclipse numbers above were using Sun's JRE 6u10. I also tried the Windows 2000 cases with an IBM 1.6 JRE and the SWT snippet crashed at 810M (smaller), while the eclipse browser view crashed at 1038M (larger?!). I don't know how to explain these differences, but my guess is that you're using an IBM JRE. If so, I would suggest trying a Sun JRE to see how high your number gets. Since I have not been able to make the browser view crash in the 100M-200M range as described in comment 0 I need more details about the configuration(s) you see this on. In particular: - it is eclipse 3.4.2 right? - any other OSs (Vista, Windows 7, etc.) you've seen this on - IE version - Flash player version - JRE version
Hi Grant, thanks for looking at the problem quickly. You are right, we are using the IBM J9 JVM. Note that I noticed that when user increases the heap size Xmx, the problem occurs more often for some reason. In one scenario where an user hit this problem, he increased the heap size to -Xmx1480, and the problem occurred a lot more quickly (at a much lower browser mem usage). (In reply to comment #4) > I've been experimenting with the attached page and found the following so far > (tried with eclipse/swt 3.4.2 and latest from the 3.6 stream): > > Config: Windows 2000 with IE6 and Flash Player 9 > - stand-alone external IE 6: flash9.osx crashes at 1369M > - small SWT snippet showing Browser: flash9.ocx crashes at 1245M > - eclipse internal browser view: flash9.ocx crashes at 810M > > Config: Vista with IE8 and Flash Player 9 & 10 (both versions behaved > similarly) > - add 150M-200M to each of the Windows 2000 numbers, no other difference > > I haven't tried on an XP machine yet, but when I do I'm not expecting to see > much difference. > > The stand-alone IE number shows the point at which the Flash player crashes > with no swt/java involvement, and there's no way for swt to avert a crash > that's happening in flash9.ocx. The SWT snippet case gets almost as high as > the stand-alone IE case, and I think the difference is the overhead of having > java+SWT loaded. I think the eclipse internal view case is similar, the > difference is the overhead of having java+eclipse loaded. > > The swt/eclipse numbers above were using Sun's JRE 6u10. I also tried the > Windows 2000 cases with an IBM 1.6 JRE and the SWT snippet crashed at 810M > (smaller), while the eclipse browser view crashed at 1038M (larger?!). I don't > know how to explain these differences, but my guess is that you're using an IBM > JRE. If so, I would suggest trying a Sun JRE to see how high your number gets. > > Since I have not been able to make the browser view crash in the 100M-200M > range as described in comment 0 I need more details about the configuration(s) > you see this on. In particular: > > - it is eclipse 3.4.2 right? > - any other OSs (Vista, Windows 7, etc.) you've seen this on > - IE version > - Flash player version > - JRE version
There is an inverse relationship between the max heap size and Flash crashing. The larger the java heap, the less memory available for non-java stuff, like dll's for embedded IE or Flash. To be able to allocate more memory to the Flash player you need to use a smaller max heap size.
Right, the problem is not that the java heap is running out of memory. When I increase its size I also see the crash happen earlier, so at least I can reproduce your case better now. So my first suggestion is... don't do this :). As comment 4 said, swt cannot stop the Flash plugin from crashing. The best that can be hoped for is to match stand-alone IE, since this is the highest memory use the example reaches before crashing. To reach this I think the Flash plug-in needs to be running in a process != eclipse. The only way to do this currently is to launch an external IE with the Program class. The SWT Browser does not support out-of-process use. As a side note: Since your example crashes in stand-alone IE, I would also suggest trying to log a bug with Adobe with the example.
