Optimization bug

Question

I am using the Flex Builder 2.01 Eclipse plugin on a MacBook
Pro. I have some code which takes an object tree and recursively
wraps all of the Array properties of objects to ArrayCollections.
So for example, the tree starts with an object Foo, which has a
bunch of properties on it. One of these properties could be an
Array. This Array property will be replaced by an ArrayCollection,
and then for each object in the array, the same process is
performed. Here is some example code:
public static function convertObject( o:Object ):Object
var classInfo:XML = describeType( o );
if ( [email protected]() == "Object" )
for ( var key:String in o )
var value:Object = o[key];
if ( value is Array )
o[key] = convertToArrayCollection( o, value as Array );
return o;
public static function convertToArrayCollection(
parent:Object, value:Array ):ArrayCollection
var arrayCollection:ArrayCollection = new ArrayCollection();
arrayCollection.source = value;
for ( var i:int = 0; i < value.length; i++ )
convertObject( value
, changeListener );
return ArrayCollection(arrayCollection);
So, when I use the default compiler settings in Flex Builder
2.01, this will intermittently fail. The behavior I get is that
when I iterate through the properties of the object I am
converting, some of the properties are not there, and other
properties are duplicated. So for example, if my object has these
properties:
foo
bar
myarray
When I iterate through all the properties, I get
foo
bar
foo
bar
instead of
foo
bar
myarray
I first tried to debug this issue, thinking there was some
problem with my code. But whenever I ran the debug version, I
didn't see the problem. Finally, under compiler options, I set
-debug=true and -optimize=false and the problem appears to have
went away. So, it appears that there is some problem with the
optimization in the compiler.

Answer 1

Thanks for confirming this.
No, this happens neither in an Open Source package nor in an important product. This is an internal product, which is continuously developed with Sun Tools since 1992 (with incidents like this one being very rare).
I am a bit concerned with this bug though, because it might indicate a weakness in the area of C++ inlining (after all, the compiler fails to correctly aggregate a sequence of three fairly simple inline functions, something which is quite common in our application). If, on the other hand, this is a singular failure caused by unique circumstances which we have hit by sheer (un)luck, it is always possible to work around this: explicitly defining a assignment operator instead of relying on the compiler-generated one is sufficient to make the bug go away.