Re: [Gnash-dev] BLOCKER bug in string_table bug

[strk]

On Tue, Feb 05, 2008 at 08:46:13PM +0100, strk wrote:
> I think I found a reason for two "Color" strings
> to be in the index. We are actually creating two at
> startup time:
> 
>         string_table::svt( "color", NSV::PROP_COLOR ) // this is key 9
>         string_table::svt( "Color", NSV::CLASS_COLOR ) // this is key 106
> 
> The mass-load doesn't use "find", and thus fails...

I made some tests.. both labels (in SWF6, thus case-insensitive)
are supposed to exist on enumerate.

        // This one will trace "_global.Color"
        AsSetPropFlags(_global, "Color", 0, 1);
        for (var i in _global) trace("_global."+i);

        // This one will trace "tf.color"
        tf = new TextFormat();
        for (var i in tf) trace("tf."+i);

        // This one will trace "_global.Color" 3 times !!
        _global.color = 1;
        _global.cOlor = 2;
        for (var i in _global) note("_global."+i);

        // And this:
        trace("_global.Color: "+_global.Color+" ("+typeof(_global.Color)+")");
        trace("_global.color: "+_global.color+" ("+typeof(_global.color)+")");
        trace("_global.cOlor: "+_global.cOlor+" ("+typeof(_global.cOlor)+")");
        // will print:
        // _global.Color: 2 (number)
        // _global.color: 2 (number)
        // _global.cOlor: 2 (number)

On enumerating, each key resolves to the same value, but you still
have different keys. On searches, you always get back the last value ?

--strk;



> 
> --strk;
> 
> On Tue, Feb 05, 2008 at 11:32:45AM +0100, strk wrote:
> > 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! 
> > 
> > 
> > 
> > _______________________________________________
> > Gnash-dev mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gnash-dev
> 
> -- 
> 
>  ()   ASCII Ribbon Campaign
>  /\   Keep it simple! 
> 
> 
> 
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev

-- 

 ()   ASCII Ribbon Campaign
 /\   Keep it simple!