SharedObject created in AS2 results in RangeError "The supplied index is out of bounds" on call to getLocal.

[Zanzlanz]

To ensure forward compatibility, I want the old AS2 Shared Objects to work in the new, AS3 version of my application (Publishing in Flash Player 11.1). For some reason, this is not the case.

The AS3 code is simple:

var so:SharedObject = SharedObject.getLocal("ExistingAS2SharedObject", "/");

Shared Objects created in AS3 work perfectly fine in this scenario, but they break when they were originally created in AS2, causing the RangeError "The supplied index is out of bounds" on the line of code above. I do not have access to AS2 code (I use CC), but it saves and loads fine by itself, as well, so there should be no other problems.

I made sure to set default encoding to AMF3, although I believe that is redundant. Are there known issues with AS3 opening AS3 shared objects? Do I need to take a different approach? Thoughts?

[kglad]

i don't see that problem.

[Zanzlanz]

kglad wrote:

i don't see that problem.

I wish I could make an isolated example of this, but Adobe doesn't support AS2 in CC, which is a shame.

Here are some old related topics that didn't seem to address the actual problem either. The second link uses Flex, so I don't know how relevant it is:

- Why does AS3 error when opening AS2 sharedObject

- http://flexcoders.10928.n7.nabble.com/SharedObject-getLocal-throws-RangeError-td23295.html

The full error is:

RangeError: Error #2006: The supplied index is out of bounds.

    at flash.net::SharedObject$/getLocal()

    at [the relevant line of code that I supplied in the original question]

[kglad]

i created an as2 sharedobject with flash cs6 and tested that it saved and retrieved data including an array.

i then saved that fla as an as3 file and opened in flash cc and retrieved the data without problem.

[Zanzlanz]

Thank you for attempting to reproduce the issue.

It seems as though this problem is very weird. I did some further testing.

If I create the shared object in AS2, and then open it in the AS3 application, it will break and cause the error described.

However, instead of opening it the AS3 application, I tried opening it in a new SWF with only the following AS3 code (not unlike the code that breaks it in the AS3 application):

var so:SharedObject = SharedObject.getLocal("ExistingAS2SharedObject", "/");

for(var i:String in so.data) trace(i);

Then, when I opened it with the AS3 application, the error does not happen! I don't know why this intermediate step is necessary for it to work. If I don't do this intermediate step, the runtime error occurs and the Shared Object files are deleted...

In the AS3 application, I put the getLocal code at the very start of the program, so nothing should be interfering with it beforehand.

[kglad]

i don't understand your last message.  here's what i used to test in as2 and as3:

var a:Array = ['a','b','c'];

trace('init: '+a);

var so:SharedObject = SharedObject.getLocal('test_so1','/');

if(!so.data.testvar && !so.data.a){

so.data.testvar = 'hi';

so.data.a = a;

trace('save: '+so.data.a);

so.flush();

} else {

trace(so.data.testvar);

trace(so.data.a[1]);

}

[Zanzlanz · Accepted solution]

Well I worked on this bug for a couple more weeks. I'm one hundred percent convinced it's a problem with Flash. Either way, here is the solution that I believe fixes the issue:

- Use AMF0 encoding. If you must use AMF3, set the "Local playback security" to "Allow local files only". Running the SWF in the browser will override this, so the issue will still occur, however the issue will no longer happen in standalone.

- Set the "Local playback security" to "Allow network only". It will not work otherwise.

Some other things that affect the bug include:

- If the AS2-created shared object was accessed by AS3 at any point, the bug will no longer occur. I believe this is because it is converted to AMF3. This is likely to happen if you test under "Allow local files only", for example.

- The bug may no longer be reproducible if Flash Player is using a lot of RAM. For example, I had Flash Player using 1.4 Gb of RAM, and the bug seemed to have stopped misbehaving, making it difficult for me to debug.

- The behavior of the bug may change whether or not the SWF is running through the debugger or standalone. I didn't test this enough to confirm though.
- Putting a try/catch around the code does not stop the shared object from being destroyed. Additionally, the code will return if a different shared object tries to access it too. Everything behaves as expected if the bug is not occurring in the first place.

Some things that do not affect the bug include:

- Other code and library items loaded in the app don't affect the issue (assuming it isn't meant to interfere with the code of course). The bug also happens in classes, and SWC files.

- Flash Player version and IDE version have no affect on the bug, so it seems.

I hope this helps someone else in the future! And I hope that I never had to run into this bug again, haha.