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 > [email protected] > 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. _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
