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