Wed 15 Nov 2006 09:59:22 AM UTC, comment #12:
Committed a patch in release branch for this. Please see if you can reproduce.
|
Tue 14 Nov 2006 08:46:22 AM UTC, comment #11:
I tried yesterday protecting reads and writes of m_loading_frame and found out that was not the problem.
Rather it seems a problem with action execution. The SWF contains
a GOTOFRAME tag followed by a PLAY tag, I suspect that the order
of execution is somehow dependent on timing again, so possibly
the sprite_instance actions vector is being concurrently read/modified by the parser and executor threads. Will need to try protecting that from concurrent reads.
|
Mon 13 Nov 2006 05:25:11 PM UTC, comment #10:
Ok, found the problem being with m_loading_frame read
being object of threads race. Basically the WaitForFrame
action handlers read that variable w/out obtaining the loading
mutex, so possibly reading a dirty value.
If we make the WaitForFrame action always really wait for
the frame (there's a define ready for this in ASHAndlers.cpp)
the movie always work fine, as the ensure_frame_loaded() takes
care of proper locking. This can be likely fixed by locking
the loader for the whole ::advance duration, but we avoided this so far.
|
Mon 13 Nov 2006 04:43:12 PM UTC, comment #9:
I tried adding a "bandwidth restrictor" in the parser (sleep 1 millisecond at every iteration in the tag loading loop) and with that activated I can always reproduce the bug.
IIRC there was another such case and turned out that the same
bogus behavior was obtained with the proprietary player.
See if you can reproduce it with it by loading from the newtork
(not that we necessarly want to be as bogus as the proprietary
player, but just to know...)
|
Mon 13 Nov 2006 09:50:29 AM UTC, comment #8:
So this is likely a race condition. we curretnly don't lock each other thread so that parsing and actions execution (::advance)
are mutually exclusive, rather we only lock while ensuring
a specific frame has been loaded, and we ensure a frame is loaded
before preceeding with executing it's actionscript.
Next thing to try might be locking for the whole ::advance
duration instead (and also extend locking to user actions, maybe)
|
Mon 13 Nov 2006 09:33:44 AM UTC, comment #7:
Note that if I undef LOAD_MOVIES_IN_A_SEPARATE_THREAD it works fine.
|
Thu 21 Sep 2006 02:58:36 PM UTC, comment #6:
Yep, it now does the same thing for me.
|
Tue 19 Sep 2006 02:15:44 PM UTC, comment #5:
Just tried a 'rm -rf gnash' and a clean checkout/recompile but I get again the same problem.
|
Tue 19 Sep 2006 12:47:07 PM UTC, comment #4:
I can't reproduce the bug :/
Can you try again after update ?
|
Tue 19 Sep 2006 09:47:33 AM UTC, comment #3:
I am using current gnash:
Gnash 0.7.1-cvs-20060919
|
Tue 19 Sep 2006 08:17:01 AM UTC, comment #2:
Oops, sorry, wrong bug...
What version of gnash are you running ?
|
Tue 19 Sep 2006 08:13:48 AM UTC, comment #1:
It seems that Equal action handler is broken, I'm working on it.
Stack: "EvalGuess" | "628" | "628"
Global registers: "undefined" | "undefined" | "undefined" | "undefined"
Local registers:
EX:
Equal
PC is now 139.
Stack: "EvalGuess" | "false"
Global registers: "undefined" | "undefined" | "undefined" | "undefined"
Local registers:
|
Mon 18 Sep 2006 01:36:27 PM UTC, original submission:
With this game:
http://funcop.net/bombgame.swf
I see only for a fraction of time the screens with loading and play. At the play screen it should instead stop, until I click on the play button.
Note that if I change
#if 1
size_t startup_frames = 1;
#else
to
#if 0
in server/parser/movie_def_impl.cpp
it works fine.
|