Re: [Gnash-dev] Crash bug with possible fix

[strk]

I added and enabled some debugging for this case. 
There are *two* textfields with VariableName:

(1) : works

09:48:44: registerTextVariable(_root.winner) called
09:48:44: Variable text Path: _root, Var: winner
09:48:44: target sprite (0x8054998) does NOT have a member named winner (no prob
lem, we'll add it)

(1) : failes

09:48:44: registerTextVariable(_root.getVar.result) called
09:48:44: Variable text Path: _root.getVar, Var: result
09:48:44: WARNING: VariableName associated to text field refer to an unknown tar
get (_root.getVar/result)

So, the VariableName associated to the textfield, in the second case
is '_root.getVar.result', and it is parsed as if a variable called
'result' has to be found in a target named '_root.getVar', which is NOT
found.

Now, looking at the SWF with a dumper (listswf, from Ming) I see that
'getVar' will eventually exist, naming a PLACEOBJECT2, but occurring
*after* the definition of the EditTextCharacter.

So, Gnash doesn't work because the textVariable is attempted to be
registered at instantiation time (when the TextField is *placed* on
stage), and at that time there's on 'getVar' character (will be added
later).

I wonder if the official player is able to play this correctly (in
case the SWF really uses that VariableName, btw). If this is the
case we'll have to refactor the code to take referencing yet-to-be
instanciated chars in the VariableName as a possible thing.

--strk;

On Mon, Nov 13, 2006 at 09:20:20AM +0100, strk wrote:
> On Sun, Nov 12, 2006 at 11:30:07PM -0500, dolphinling wrote:
> > I have a file at http://dolphinling.net/gnash/5.swf that crashes gnash. The 
> > file was reduced using swftools to the minimum needed to crash from 
> > http://images.neopets.com/faerieland/wheel_v1.swf .
> > 
> > When it crashes it prints the following:
> > gnash: edit_text_character.cpp:849: void 
> > gnash::edit_text_character::registerTextVariable(const std::string&): 
> > Assertion `dynamic_cast<sprite_instance*>(target)' failed.
> > Aborted
> > 
> > Having run through a debugger, it looks like target is null at that point, 
> > and as_environment.cpp:find_target() can indeed return null in at least two 
> > ways. So it looks like casting null to a sprite_instance* doesn't work.
> > 
> > The funny thing is, target is non-null before that, and if I comment out 
> > the line setting it null, it doesn't crash.
> 
> Nothing funny about that, the crash is just the failed assertion(), which
> is expected to fail if given a NULL pointer.
> 
> > I don't understand all the code, so I don't know if the correct fix is to 
> > make find_target() not return null in this case, to null check before 
> > setting target, or to remove that line entirely, but null checking seems to 
> > work for me, so here's a patch for it.
> 
> Well, it seems that the SWF contains a fully-qualified variable name
> referencing an unexisting "target" (the path part in a path/variable spec).
> If this is the case this would be a malformed SWF. What to do in this case ?
> I'd just NOT set the text variable and warn user (IF_VERBOSE_MALFORMED_SWF).
> 
> --strk;

-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII.