[Gnash-dev] BLOCKER bug in string_table bug

[strk]

Chad, I've been tracking an ActionScript bug for 3/4 days and finally
found the culprit beign the string_table.

The testcase is a pretty complex SWF6 application, often using
a variable named 'color'. Of course we also have a "Color" class
so the case-insensitive "Color" string should be already registered.

I'd expect that any string_table::find("color") call would return
the key of the already-existing "Color" class since we're in SWF6,
but it seems it sometimes does and some other times doesn't.

The visible effect is that an object member named "color" unexpectedly
changes it's value from the one to the other (from the expected
value to the "Color" class value: a function).

It was very hard to track down as this mis-reference changes depending
on other code being run before or after the point of failure.
I belive this could be due to insertions in the string table changing
order of the strings thus returning one or the other based on some
complex heuristic.

I would NOT know how to produce a testcase for this, but maybe
you can help once you find out the problem.

The way I found out was by printing both name and key of "color" 
named variables while getting/setting them:

 DEBUG: getting member 'color' (key: 106, value: color) of object 0x82bf6fc
 TRACE: toolbar.as:113: theGui:[object(gnash::object_as_object):0x8233c20] 
theGui.color:16755438
 DEBUG: getting member 'color' (key: 9, value: color) of object 0x81d72ec
 TRACE: toolbar.as:117: theGui:[object(gnash::object_as_object):0x8233c20] 
theGui.color:
 DEBUG: getting member 'color' (key: 9, value: color) of object 0x82c5574

The actionscript code between lines 113 and 117 are:

  113: trace(__FILE__+":"+__LINE__+": theGui:"+debug(theGui)+" 
theGui.color:"+theGui.color);
  114:
  115: var button = toolbar[name];
  116:
  117: trace(__FILE__+":"+__LINE__+": theGui:"+debug(theGui)+" 
theGui.color:"+theGui.color);

You can see that simply setting a 'button' local variable and getting a <name> 
object member
changes resolution of the "color" string from key 106 to key 9.
I belive key 9 is the Color class (low number, and evaluates to the empty 
string)
while key 106 is a new key added the first time AS code requested for a "color" 
string.

Now, I belive key 106 should have never been created, having a key 9 with a 
matching
case-insensitive label ("Color"). Does it sound ?

I think we want this bug fixed before we ship 0.8.2.

--strk;

 ()   ASCII Ribbon Campaign
 /\   Keep it simple!