Mon 02 Apr 2007 06:11:05 AM UTC, comment #14:
This bug is likely due to reverse execution of frame tags.
current testcase for this are : testsuite/reverse_execute_PlaceObject2_test1.c and attached test.swf(a testcase made by dongdong) here.
(file #12370)
|
Wed 14 Feb 2007 09:32:41 AM UTC, comment #13:
What we need is a test that fails with previous code,
to avoid future regressions of this kind
(I could only detect this regression because I've a set
of movies on my machine, would be better to have actual
testcases instead to catch such regressions).
|
Wed 14 Feb 2007 09:20:24 AM UTC, comment #12:
>>Does this new test fail with the code before the reversion
>>patch ?
I guess not. My local source(before the reversion) could pass this test.
|
Wed 14 Feb 2007 08:50:48 AM UTC, comment #11:
Does this new test fail with the code before the reversion patch ?
|
Wed 14 Feb 2007 06:31:53 AM UTC, comment #10:
Done.
Another simple but good testcase:) We need to do sth. again with the goto_frame now.
|
Wed 14 Feb 2007 05:47:22 AM UTC, comment #9:
Other testcase will come soon.
|
Mon 12 Feb 2007 02:19:30 PM UTC, comment #8:
I've committed the "reversion" patch. Looking forward for
other testcases.
|
Mon 12 Feb 2007 09:27:17 AM UTC, comment #7:
I'm running both with previous and current code, and it seems
that both fail. A good testcase reproducing the behaviour
of the attached movie would be helpful (ie: failing with the
new code, succeeding with the previous).
|
Mon 12 Feb 2007 09:09:32 AM UTC, comment #6:
added a new testcase.
I haven't convert the current source back. Because I am still a little bit suspicious of the attached path. However, my local source is based on this patch. I will go on testing it for one more day.
|
Mon 12 Feb 2007 06:58:50 AM UTC, comment #5:
Got better understand of previous code.
The previous version of goto_frame seems OK. m_action_list is just a list of pointers. Clear m_action_list does not destroy the real action buffer.
BTW, both the current and the reverted Gnash could not deal with consecutive gotoFrames properly. But I guess it's not the fault of goto_frame. I will commit a new testcase soon.
|
Mon 12 Feb 2007 04:19:31 AM UTC, comment #4:
>> After my last commit for _frame0_chars it seems that reverting
>> your patch doesn't even trigger any failure in our testsuite.
>> Can you confirm ?
Confirm. Seems nothing wrong with previous goto_frame implementation. I am going to make more strict test today.
|
Sat 10 Feb 2007 01:50:04 PM UTC, comment #3:
Attached a patch reverting the incriminated change. To make tests easier.
(file #11957)
|
Sat 10 Feb 2007 01:45:43 PM UTC, comment #2:
After my last commit for _frame0_chars it seems that reverting your patch doesn't even trigger any failure in our testsuite.
Can you confirm ?
|
Sat 10 Feb 2007 01:19:01 PM UTC, comment #1:
I confirm that reverting this patch fixes the problem:
2007-01-29 08:33 zoulunkai
* sprite_instance.cpp (1.140), sprite_instance.h (1.59): fixed goto_frame_test(bug #18845). the next step is to make testcase more complicated
I guess it makes a good case for a more complicated test...
|
Sat 10 Feb 2007 01:11:38 PM UTC, original submission:
The file is here:
http://weebls-stuff.com/toons/flash/6964trev3c.swf
It used to work, now clearly fails (visually seeing it)
and failure is accompanied by these kind of errors:
WARNING: move_display_object() -- can't find object at depth 35
It seems these errors are coming out often lately, maybe
related to the goto_frame fixes ?
|