bugGnash - The GNU Flash player - Bugs: bug #21074, 3dtris makes gnash unresponsible

 
 

bug #21074: 3dtris makes gnash unresponsible

Submitted by:  Sandro Santilli <strk>
Submitted on:  Fri 14 Sep 2007 06:11:23 AM UTC  
 
Category: ActionScriptSeverity: 4 - Important
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Sandro Santilli <strk>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 09 Oct 2007 08:02:31 AM UTC, comment #19:

Ok, thanks for the info.
In another testcase (or was it the same? can't remember).
I noticed that NDEBUG define would change CPU usage from 100% to 40%-60%. Maybe this is another case.
Probably worth another wiki page linking from http://wiki.gnashdev.org/wiki/index.php/Profiling

Sandro Santilli <strk>
Project MemberIn charge of this item.
Tue 09 Oct 2007 07:48:26 AM UTC, comment #18:

Dunno how to disable rendering completely.
Disabling draw_shape eliminates 99% of the rendering process. I only see the gray background and one outline. But no change in CPU usage.

Anyway, disabling "Gui::display()" still keeps CPU usage high.

Add this to the very beginning of Gui::display():

static int counter=0;
counter++;
if (counter>50) {
printf("NOT rendering...\n");
return true;
}

It will render enough to see the start screen. Once you click on the level the screen will not change (because it already stopped rendering) but CPU goes high (from <2% to 40% on my machine).

So I think this proves that:
- it's not rendering
- it's not InvalidatedRanges (at least not the part that computes the invalidated regions)
- it's not one of the display() methods

Looks like a pure ActionScript issue...

Udo Giacomozzi <udog>
Project Member
Mon 08 Oct 2007 05:35:10 PM UTC, comment #17:

mmm.. can you disable rendering completely somehow ?
minimizing the window maybe ?

Sandro Santilli <strk>
Project MemberIn charge of this item.
Mon 08 Oct 2007 05:03:01 PM UTC, comment #16:

Are you sure it's a render-handler problem? When turning draw_shape() into a no-op the CPU usage remains equally high. Nearly any drawing function (shapes, shape outlines, glyphs, ...) works through draw_shape().

Shrinking the window to 10% doesn't make any difference either.

I get the feeling it's not a rendering thing..

Udo Giacomozzi <udog>
Project Member
Mon 08 Oct 2007 09:56:36 AM UTC, comment #15:

Already attached: file #14067

Sandro Santilli <strk>
Project MemberIn charge of this item.
Mon 08 Oct 2007 09:52:52 AM UTC, comment #14:

Ok, I'll have a look at it. How to compile the AS source? Or maybe please just attach the final SWF file...

Udo Giacomozzi <udog>
Project Member
Mon 08 Oct 2007 08:45:35 AM UTC, comment #13:

The ActionLimit seems also fixed now. CPU usage is high (not 100& though). Rendering seems broken, but gnash is responsive and you can also see score changing (the left-vertical number).

UdoG: any entusiasm in trying to figure out the rendering part ?

NOTE: I didn't test with other renderers, but no other renderer I know of supports the drawing API anyway

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 03 Oct 2007 11:25:58 AM UTC, comment #12:

I fixed a couple of ActionShiftRight problems.
This seems to fix the high memory.
Instead we now get an abort on uncought exception:

terminate called after throwing an instance of 'gnash::ActionLimitException'
what(): Loop iterations count exceeded limit of 65536. Last branch was from pc 569 to 503.
Aborted (core dumped)

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 03 Oct 2007 08:41:21 AM UTC, comment #11:

Found the culprit (or one of them):

32800 >> 5 (ActionShiftRight)
should give 1025, while in gnash it gives -1023.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 03 Oct 2007 08:00:09 AM UTC, comment #10:

The original movie is attached.
The problem of not properly running the original movie is
in ActionScript, not AGG per-se.

Anyway, sucking up all memory could be considered a problem on itself, given a malformed or even intentionally killer movie.

AGG is responsible for memory consumption. Run the result of compiling the attached source (killerdrawing.as) with gnash and another player to compare.

(file #14067)

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 03 Oct 2007 07:51:42 AM UTC, comment #9:

Any change to get the source / decompile the original SWF to see how it works?

Note there are lots of beginFill() but no matching endFill(). AFAIK this is legal, but does Gnash deal correctly with this?

So, AGG is not the problem?

Udo Giacomozzi <udog>
Project Member
Wed 03 Oct 2007 07:37:13 AM UTC, comment #8:

Added debugging support for drawing api, and the resulting drawable is really huge. The script is aborted due to action limit hit so is not complete, but the calls that went trough are enough to reproduce the problem.

Note that all drawing is outside the visible area, adding an ._y shift manually brings them inside. In the original SWF it is likely that the matrix is set before as the _y shift give us a reproduction of the actual problem.

Note also that the proprietary player is also killed by the resulting swf. The problem is of course in ActionScript, as we should likely NOT get those values, and we should get out of a loop earlier which we fail to do. Anyway it is interesting to find a way to deal with such killing scripts.

Attached is the .as file, you can compile using 'makeswf'.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Tue 02 Oct 2007 05:36:39 PM UTC, comment #7:

The movie is stuck trying to display this drawable:

DEBUG: Drawing the drawable of sprite _level0.pit_mc (131069 paths, 262135 edges)

agg triggers eat of all memory.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Tue 02 Oct 2007 04:20:32 PM UTC, comment #6:

It seems to me that CPU is busy in the rendering phase.
Action execution is aborted due to max branch-back limit.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 26 Sep 2007 09:58:12 AM UTC, comment #5:

Confirmed, memory jumps really high.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 26 Sep 2007 07:49:34 AM UTC, comment #4:

it hangs the whole system here, not only gnash, because it uses up all system memory quickly.

some kind of memory leak here.

Dongxu Li <butdiene>
Fri 14 Sep 2007 06:06:36 PM UTC, comment #3:

It seems it's a problem of script limits.
We're probably failing to exit from a loop (meeting loop exit condition).
Anyway, in these cases we should not hung up forever.

About hitting "script limits", should this condition abort execution of the whole set of queued actions or just a subset of them ? I mean, the whole ActionQueue or only a single element ?

Sandro Santilli <strk>
Project MemberIn charge of this item.
Fri 14 Sep 2007 03:53:41 PM UTC, comment #2:

The movie runs at 24FPS and I suspect it makes aggressive use of the drawing api. I'm currently doing some optimizations and cleanups of bounds computation.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Fri 14 Sep 2007 06:13:10 AM UTC, comment #1:

Just a note, this is nothing new, it's a long standing bug (I guess since we implemented the drawing api)

Sandro Santilli <strk>
Project MemberIn charge of this item.
Fri 14 Sep 2007 06:11:23 AM UTC, original submission:

Test case is file #12885

Once you select the level you want to play, CPU goes 100% and gnash becomes unresponsive. Gdb says it's doing hard work with drawing api.

Sandro Santilli <strk>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #14067:  3dtris.swf added by strk (19KiB - application/x-shockwave-flash)
file #14066:  killerdrawing.as.bz2 added by strk (442KiB - application/x-bzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by udog (Posted a comment)
  • -unavailable- added by strk
  • -unavailable- added by butdiene (Posted a comment)
  • -unavailable- added by butdiene
  • -unavailable- added by strk
  • -unavailable- added by strk (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 09 Oct 2007 08:02:31 AM UTCstrkStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Mon 08 Oct 2007 08:45:35 AM UTCstrkStatusNone=>Ready For Test
    Wed 03 Oct 2007 08:00:09 AM UTCstrkAttached File-=>Added 3dtris.swf, #14067
    Wed 03 Oct 2007 07:39:52 AM UTCstrkAttached File-=>Added killerdrawing.as.bz2, #14066
    Tue 02 Oct 2007 05:36:39 PM UTCstrkCarbon-Copy-=>Added udog
    Wed 26 Sep 2007 07:49:34 AM UTCbutdieneCarbon-Copy-=>Added butdiene
    Fri 14 Sep 2007 06:06:36 PM UTCstrkCarbon-Copy-=>Added zoulunkai

    Back to the top


    Powered by Savane 3.1-cleanup1