Flash Player crashes in IE 11 when Flex alert dialogs are thrown

[DEldstrom]

Having similar issue but with our own flash app with 1703 Windows 10, IE11 and player version 26.0.0.151.
We use Apache Flex to create our application and sometimes (not always) when a alert dialog is opened it crashes the flash player totaly leaving only a exclamation mark in the browser window.

I have tried many things to get it to work again but since it crashes completely silent (not even debug player with attached debugger shows anything) so i am out of ideas what to try to get it to work.

Hardware acceleration on or off does no difference and we get the same error on various computers.

[jeromiec83223024]

I've branched this to a new discussion, since your symptoms are unique from the thread you posted in.

The best way for us to debug a crash is to reproduce it under a C++ debugger.  A URL and steps to reproduce the problem, or a simple test example that demonstrates the issue would be ideal.

Short of that, a minidump would be useful.

This guide is a bit outdated, but it covers the gist of it:

https://helpx.adobe.com/flash-player/kb/report-flash-player-crash.htmlash

[DEldstrom]

Its a bit hard to do a testcase since this problem is a part of a much bigger application but i have tracked it down, somehow to memory usage.

When opening a Alert dialog with the default modal behaviour with the blurred backround the app allocated 300mb memory for the blurred background with the application we develop. The fix for me was to write my own version of the Alert dialog and place a simple overlaying canvas behind the dialog window and disable the default modal. This, at least so far makes IE11 not crash so there has to be something weird with memory usage in IE11 (and thats what i see also when using Adobe Scout, memory spikes when opening modal with the blurred modal background).

Anyway, it seems as i have managed to work around the problem for now but i still think there is something not right with the current version of the flash player.

[jeromiec83223024]

That's a great lead, and depending on the browser, we *will* crash safely in out of memory conditions. 

It's not surprising that you would see memory allocated when opening the modal, but ActionScript is a garbage collected language, and it should ultimately be recovered.  That said, 300MB seems excessive.  I'm definitely interested in researching that more deeply.

What version of the Flex SDK are you using?

[DEldstrom]

We are currently using Apache Flex 4.16.0 FP23.0 AIR23.0 en_US and compiling to minimum version flash player 13.0.

We use Flashdevelop as IDE.

Yeah, 300mb is excessive and it seems to be located in bitmap and bitmapcache. It is, as you say released after it is closed so all GC stuff works as it should but it somehow gets too much for the player and it crashes.

Our applications is quite heavy on loading bitmaps and can sometimes utilize a lot more than this amount of memory so it is strange that it crashes. My computer at the time has had up to 13gb of free ram so it is not associated with that, seems local to the browsers plugin environment.

[DEldstrom]

Something that i am considering is also that it might not be a flash player issue at all and could be a Microsoft IE11 issue with their active x plugin environment?

[DEldstrom]

Sometimes things worked as it should, more often if i used a small browser window where the blurred background did not get as big in memoryusage but when using fullsize running at resolution 1920 x 1080 it crashed every time a dialog with modal background was opened.

[jeromiec83223024]

It's actually even more convoluted.  ActiveX doesn't technically exist on Win8+, and the Flash Player that ships for Win8+ is significantly different from the ActiveX module that ships for Win7 and below.

Until we debug it, it's hard to say why that's happening.  It's also quite possible that it's a bug in the Flex framework.

That said, if you had a 4K rectangle (3840 x 2160), that's 8294400 pixels.  If you assume a 32-bit value for each pixel, that's 265420800 bits, or ~33MB.  I could see a situation where you ended up with a couple copies in memory simultaneously (the original, the one with blur applied, maybe a couple intermediary copies for some kind of optimization), but I don't know where the rest of that 300MB is coming from, unless there's processing happening when that alert pops that might be consuming it.

[DEldstrom]

If it is a bug in the flex framework that would be in combination with that flashplayerversion since we have used this Flex SDK version for at least 2 months now.

[jeromiec83223024]

Yeah, I was just thinking out loud.  The next step is to see if I can reproduce the spike in memory usage with a sample app, and then try and isolate a changelist that precipitates a large increase in memory usage.  We have enough to go look for concrete data at this point.

Thanks!

[JasbeerSingh]

Hi

I tried reproducing your issue using the example from the below link:

Alert - Adobe ActionScript® 3 (AS3 Flex) API Reference

Each time an alert appears, there is a slight memory bump, expectedly due to the bitmap used for the grey background(which also goes away as we close the alert). But the memory spike I observed was always close to 10-15MB which is nowhere close to your observation.

It would be helpfull  if you could log a Tracker bug along with a sample application and observations using the latest flash player and AIR.

[jeromiec83223024]

JasbeerSingh​ - I think you'd see a more interesting delta if you used a large, hard to compress background (say, 3840 × 2160 of 10pt lorem ipsum, or black and white "snow") and threw the alert over the top.  Also, note that they're using one of the more recent Apache Flex SDKs.  It would be interesting to know whether or not there's a difference in behavior between the last official Adobe Flex release, and the current Apache Flex SDK.  That said, this may be a fact of life, where the answer is simply to optimize the behavior by using a compressible background like a solid color, to minimize the overhead of that alert control (or write a custom alert that isn't transparent).  If there's a large delta in usage introduced in Apache Flex, we should probably file a bug with them.

[DEldstrom]

I did create a tracker bug but i, aswell as you can not reproduce it outside of our app.

Tracker

It seems to be isolated when using some kind of combination of components or amount of memory used or something like that, i cant be sure since i went on and made a alert version that just adds a canvas as overlay behind it so i dont use the built in modal method any more. In other words, there is no more any bitmap created when the alert dialog is shown and the memory usage is not a problem any more.

If nobody else has this issue it might be local to our system only.

[jeromiec83223024]

The fact that your workaround solves the memory issue informs my theory that generating that blur might be inefficient.  Using a big uncompressable background should bear that out. 

As you pointed out, it's also quite possible that there's an interaction with another Flex component that causes many instances of intermediary bitmaps to be generated.  I actually like that theory a little bit better to be honest.  Flex has some quirky behaviors around scaling when rounding errors are in play on high-resolution displays, and I wouldn't be surprised if there's some component hitting a pathological case where it just keeps redrawing itself as that alert background gets generated.

We're really just guessing without stepping through the running application under a C++ debugger, but my sense, given that the difference in outcome is what Flex components are visible in the background, is that it's an issue in the Flex framework, and not in Flash Player itself.

It's also quite possible that if you mentioned it to the Apache Flex maintainers, that they're aware and could suggest other workarounds, if this one is inadequate for you.