A few weeks ago there were several reports of issues something along the lines of:

Recently we upgraded to flash player 9.0.115.
We are still using Flex 2.0.1 hfxxx and now we regularly get the following error when we run our Flex app:

“The ABC data is corrupt, attempt to read out of bounds.”
VerifyError: Error #1107: The ABC data is corrupt, attempt to read out of bounds.
at Function/http://adobe.com/AS3/2006/builtin::apply()
at mx.core::UIComponent/callLaterDispatcher2()
[E:\dev\flex_201_borneo\sdk\frameworks\mx\core\UIComponent.as:7975]
at mx.core::UIComponent/callLaterDispatcher()
[E:\dev\flex_201_borneo\sdk\frameworks\mx\core\UIComponent.as:7918]

I did some research and found previous reports of this issue, bug entries and a Flex Technote

http://www.mail-archive.com/flexcoders@yahoogroups.com/msg55621.html

http://bugs.adobe.com/jira/browse/SDK-14121
https://bugs.adobe.com/jira/browse/ASC-2289
http://bugs.adobe.com/jira/browse/FB-8907
(there are some good notes by Erik in this bug)

http://kb.adobe.com/selfservice/viewContent.do?externalId=4a146409&sliceId=2

The notes in the 3rd bug by Erik are really the relevant bits of info:

ASC shipped with flex 2/2.01 had a bug in it that produced incorrect bytecode for inner named functions. This was for code like:

var f = function func(){…} // If the name ‘func’ is not present then everything works ok.

The bytecode that the compiler produced for the nested function was unsafe, and could result in one of three possibilities at runtime:

1. crash
2. Incorrect, and apparently random behavior
3. Worked ok

The VM was then fixed so that it would report a VerifyError instead of crashing or behaving erratically, but there
is no way to tell the difference between a case where it used to work ok, and where it used to crash. So we are
stuck in a situation where some code that appeared to work correctly before no longer works, but we can’t make it
work again without risking crashes.

ASC was fixed to emit good bytecode that doesn’t have this problem, which is why the same code compiled with Flex 3
doesn’t have a problem with the current VM.
After proferring this info to several customers (both by myself and through my colleagues), it was found that this was indeed the case and customers were able to modify their code quite simply to avoid this error.