gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: strk
Subject: Re: [Gnash-dev] BLOCKER bug in string_table bug
Date: Tue, 5 Feb 2008 20:46:13 +0100

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...

--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! 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]