From the code (see AvmCore::CodeContext) CodeContext appears as if it can be modified for a given MethodEnv. This is expected behaviour for security as rights are directly transferable, but for bug compatibility this is not correct. Bug compatibility should be reliant on the swf version of the most 'inner' non-builtin method on the call-chain. This is equivalent to walking MethodEnv* pointers until a non-builtin method is found, and then using the swf version of that method. Similarly, if a builtin method calls another builtin methods, then the callee should use the callers bug compat value. The AvmCore method currentBugCompatibility() appears to violate these rules or at the very least is does not make them very apparent.

I instrumented EnterCodeContext in FP10 Spicy as follows: explicit EnterCodeContext(AvmCore* core, CodeContext* new_cc) : m_core(NULL) { #ifdef DEBUG const BugCompatibility* bugCompat = core->currentBugCompatibility(); enter(core,new_cc); AvmAssert(bugCompat == core->currentBugCompatibility()); #else enter(core,new_cc); #endif } Starting up ATS10/AS3, I get a flood of assertion failures. Suspecting that EnterCodeContext was used to set up the initial context when calling into AS3 code (this looked like the case in a few examples I spot-checked), I made the assertion a bit more tolerant: AvmAssert(!bugCompat || bugCompat == core->builtinBugCompatibility || bugCompat == core->currentBugCompatibility()); ATS10/AS2 now gets to the GUI without asserting, but running the Automated Build Smokes tests again causes multiple assertion failures. It looks like player *is* changing bug compatibility via EnterCodeContext. In fact, it would take some care not to, as EnterCodeContext takes a CodeContext as an argument, and the CodeContext constructor takes a BugCompatibility as an argument. I don't see any sort of convenience functions that would automatically pass the current BugCompatibility through.

Tamarin is a dead project now. Mass WONTFIX.

Tamarin isn't maintained anymore. WONTFIX remaining bugs.