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

[strk]

I committed a patch that fixes the abort and prints
an error about this case, calling for help about
correct interpretation of the case. Please try it out,
and follow instructions printed with -v ;)

--strk;

On Mon, Nov 13, 2006 at 09:55:05AM +0100, strk wrote:
> 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. 
> 
> 
> 
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev

-- 

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