[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Crash bug with possible fix
From: |
strk |
Subject: |
Re: [Gnash-dev] Crash bug with possible fix |
Date: |
Mon, 13 Nov 2006 10:08:16 +0100 |
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.