Sat 16 Jan 2016 11:10:55 AM UTC, comment #9:
This if fixed by patch #8858, thanks !
(tested with GUI gtk,qt4,sdl,dump)
|
Fri 15 Jan 2016 10:17:22 AM UTC, comment #8:
I think moving window cleanup code from `Gtk::quitUI()` to `GtkGui::run()`
just after `gtk_main()` should help, as it ensure that the cleanup code
only run at the end, after all the drawing operations were already dealt with.
Patch included, see patch #8858 comment 1.
Gnash: 0.8.11dev (patched against git e8b111c 13-Jan-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Fri 15 Jan 2016 09:48:52 AM UTC, comment #7:
Regarding window-related assertion warnings, I have tested around and found
that they were caused by two part of screen refreshing code which took place
after frame's initial ActionScript interpretation in frame-advancing.
Warnings appeared as screen refreshing code is run without knowing that
the window was already destroyed by `GtkGui::quitUI()`.
For the reason that `secondframeexit.swf` produced no assertion warnings even
`GtkGui::quitUI()` ran before window refreshing, is that there was no graphics
change between first and second frame, thus refreshing was skipped.
I have created a variant of `secondframeexit.swf` which has graphics drawn
on second frame. When run with Gnash, you'd see that the window assertion
warnings are now appeared:
`gnash -vv secondframeexit-repaint.swf`:
Test files and source code are attached as `secondframeexit-repaint.zip`.
Gnash: 0.8.11dev (git e8b111c 13-Jan-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
Note: `secondframeexit-repaint.swf` is hand-crafted using SWFML Simple,
as SWFTools's SWFC did not recognize the built-in `getURL()` function,
and Gnash did not recognize "fscommand:" scheme in `MovieClip.getURL()`.
(file #36046)
|
Thu 14 Jan 2016 04:01:13 PM UTC, comment #6:
Patch included, see patch #8858.
This patch make sure that `GtkGui::quitUI()` calls `gtk_main_quit()` only
when `gtk_main()` is running. It also adds an `_exiting` flag inside `GtkGui`,
which once set via `GtkGui::quitUI()`, will instruct `GtkGui::run()`
to avoid entering `gtk_main()` when it was not already entered;
eliminating the freeze, though it does not fix other window-related assertion warnings.
Gnash: 0.8.11dev (patched against git e8b111c 13-Jan-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Thu 14 Jan 2016 03:40:51 PM UTC, comment #5:
Compare an contrast, using Gnash with the same diagnostic patch, but running
SWF that issues `fscommand("quit")` in second frame:
`gtk-gnash -vv secondframeexit.swf`:
You'd see that in this case, `gtk_main_quit()` is run while `gtk_main()`
was running, thus no problem on terminating the main loop.
Gnash: 0.8.11dev (patched against git e8b111c 13-Jan-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Thu 14 Jan 2016 12:52:58 PM UTC, comment #4:
First assertion error message seems to be caused by calling `gtk_main_quit()`
before the GUI code enters `gtk_main()`. I have created a dummy patch
which prints DEBUG message when `gtk-gnash` enter/terminate/exit main GTK loop,
see the attached `show-gtk-main-loop-level.patch`.
After applied the patch, I tested using `gtk-gnash -vv singleframeexit.swf`:
From debug output, you'd see that Gnash tried to terminate main GTK loop before
the main loop is run, so it failed. When the GTK main loop is run afterward,
there were nothing else to stop it, so Gnash simply froze instead of exiting.
Gnash: 0.8.11dev (patched against git e8b111c 13-Jan-2016)
System: Debian GNU/Linux 7.0 Wheezy i386
(file #36027)
|
Wed 13 Jan 2016 04:51:24 PM UTC, comment #3:
I have made a variant of test files (using makeswf and MTASC) which do
`fscommand("quit")` in second frame rather than first frame, as a comparison.
See the attached `secondframeexit.zip`.
(file #36015)
|
Sun 13 Dec 2015 12:19:20 PM UTC, comment #2:
This is still reproducible under current Gnash git version.
(`set ignoreFSCommand` statement in `~/.gnashrc` must be set to `false`)
I have created few variants of dummy Flash files (Flash 7) that tries to run
`fscommand("quit")` on the first frame, using libming's makeswf and MTASC:
- Single-frame SWF with `fscommand("quit")` code on its timeline.
- Two-frame SWF with `fscommand("quit")` code on its first frame of timeline.
- Twenty-four frame SWF with `fscommand("quit")` code on its first frame of timeline.
- Single-frame SWF with `fscommand("quit")` code in MTASC's `main()`.
and played them under multiple variants of Gnash (and also Flash Player):
- `gtk-gnash`
- Single frame case: assertion errors appeared, ActionScript executed to the end of frame, then freezes.
- Two frame case: assertion errors appeared, ActionScript executed to the end of first frame, then freezes.
- Twenty-four frame case: assertion errors appeared, ActionScript executed to the end of first frame, then freezes.
- MTASC case: assertion errors appeared, ActionScript executed to the end of `main()`, then freezes.
- `qt4-gnash`
- Single frame case: ActionScript executed to the end of frame, and terminated.
- Two frame case: ActionScript executed to the end of first frame, and terminated.
- Twenty-four frame case: ActionScript executed to the end of first frame, and terminated.
- MTASC case: ActionScript executed to the end of `main()`, and terminated.
- `sdl-gnash`
- Single frame case: ActionScript terminated at `fscommand()` call.
- Two frame case: ActionScript terminated at `fscommand()` call.
- Twenty-four frame case: ActionScript terminated at `fscommand()` call.
- MTASC case: ActionScript terminated at `fscommand()` call.
- `fb-gnash`
- Single frame case: ActionScript terminated at `fscommand()` call.
- Two frame case: ActionScript terminated at `fscommand()` call.
- Twenty-four frame case: ActionScript terminated at `fscommand()` call.
- MTASC case: ActionScript terminated at `fscommand()` call.
- `dump-gnash`
- Single frame case: ActionScript executed to the end of first frame, and terminated
- Two frame case: ActionScript executed to the end of first frame, and terminated.
- Twenty-four frame case: ActionScript executed to the end of first frame, and terminated.
- MTASC case: ActionScript executed to the end of `main()`, and terminated.
- Flash Player:
- Single frame case: ActionScript executed to the end of frame, and terminated.
- Two frame case: ActionScript executed to the end of second frame, and terminated.
- Twenty-four frame case: ActionScript executed to the end of second frame, and terminated.
- MTASC case: ActionScript executed to the end of `main()`, and terminated.
From the result and GDB backtrace, this issue seems to be specific to
`gtk-gnash` and is very similar to bug #46308 (`gtk-gnash -1` freezes on
single-frame SWF) even the exit is triggered by a different reason.
Debug log (verbosity 2, with action error log) of all SWF-Gnash variant
combination, trace log from Flash player, GDB backtrace from `gtk-gnash`
(collected from SIGQUIT core dump) are attached as `firstframexit.zip`
together with SWFs and their source files.
Gnash: 0.8.11dev (git 95763ce 8-Dec-2015)
System: Debian GNU/Linux 7.0 Wheezy i386
Flash Player: 10.1.82.76 Standalone
System: Microsoft Windows XP Professional SP3
Note #1: `fltk-gnash` is not tested as Gnash's configure script doesn't
correctly detect FLTK 1.1/1.3 header in my configuration.
Note #2: Adobe Flash Player doesn't seem to be strict on exit timing,
as it let another frame played after `fscommand()` call before terminating.
(file #35727)
|
Mon 09 Nov 2009 07:00:32 PM UTC, comment #1:
I found a case which also gets gtk to confirm that
assumption:
(lt-gtk-gnash:18504): Gtk-CRITICAL **: gtk_main_quit: assertion `main_loops != NULL' failed
this is using swfdec's test invalid-utf8-4.swf
|
Mon 09 Nov 2009 05:35:22 PM UTC, original submission:
Looks like an fscommand:quit in first frame has no effect
until a restart happens.
It is fine in second frame on.
I guess it has to do with fscommand handler not being
available at time of executino of first frame actions ?
|