[Top][All Lists]
[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!