gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] --once parameter regression


From: Sandro Santilli
Subject: Re: [Gnash-dev] --once parameter regression
Date: Tue, 29 Dec 2009 17:15:32 +0100

This may be related to a bug filed for fscommand:quit being ignored when found
in first frame. The bug there is that the GTK main loop isn't started
at time of gtk_quit
call. The assertion you get from GTK seems to be the same...
Just an hint to help  you looking at it.

--strk;

On Sun, Dec 27, 2009 at 10:59 PM, Kristian Erikson <address@hidden> wrote:
> Heya guys
>
> Here at eyemagnet we've noticed that the “--once” or “-1” parameter
> doesn't always work as intended any more with some files. In the 0.8.4
> release of Gnash the parameter could be given to files that it will
> not play now, given the same parameter, so it must be a regression. So
> basically with the 0.8.6 release we noticed that some files fail to
> play when given the “--once” parameter. To give an example please try
> playing the the following files:
>
>    gnash http://fliiby.com/fliiby-logo3d.swf
>    gnash --once http://fliiby.com/fliiby-logo3d.swf
>
> As you can see the first one plays back fine, but when given the
> “--once” flag the window never opens and the GTK-critical error is
> returned:
>    (gtk-gnash:5225): Gtk-CRITICAL **: gtk_main_quit: assertion
> `main_loops != NULL' failed
>
> I've been doing some testing and have found that not all files are
> affected by this issue, and it appears to be spread across different
> SWF versions as well. Trying to fix the problem and come up with a
> patch I first tried figuring out how the “–once” parameter is parsed.
> I found (please correct me if I'm wrong), that it basically ends up in
> “gui/gui.h” as “ bool loops() const { return _loop; }”.
>
> I then turned my attention to the initialization of the window in the
> “gui/gtk” “gui/gui-gtk” related files, hoping the error would be
> there. However I couldn't find the error there either, and the code
> structure appeared very similar to the code in the 0.8.4 release, with
> the only difference being the RunResources structure being passed down
> to new initializing windows now, as opposed to the bit_depth.
>
> I've also tried running Gnash inside a debugger, but that didn't
> reveal any more information on what causes the error either
> unfortunately.
>
> Seeing as the error does not occur on all files, and it doesn't appear
> to be at the time of initializing the window, I'm thinking that it
> must be due to something going wrong when playing the files. Maybe
> it's in the virtual machine?
>
> At this point I'm hoping for a suggestion as to where to look... Does
> anyone have any ideas as to what might be going wrong? Or maybe a
> smart suggestion I can use to help find what's causing the error? I'm
> still hoping to create a patch for this, but I think I need some help
> to do so at time point.
>
> Thanks in advance
> Kristian
>
>
> _______________________________________________
> Gnash-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnash-dev
>



-- 

 Free GIS & Flash consultant/developer  ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]