0

Like many people before myself, I'm having problems with Flash bringing down an entire CPU core (specifically, one of the threads is always using up 100% CPU).

Flash is probably running on more than 1 page (I'm using a lot of tabs), but what seemed to start this CPU usage was a bit after I started streaming a movie. That worked fine for a while, but at some point playback started skipping so I decided to investigate.

I've tried investigating through CPU sampling using Xcode's Instruments.app, and what I've found odd by walking down the sampled call stack is that about 80% of the CPU usage seemed fishy, and was due to exactly 4 recursive calls for NP_Initialize (see picture for one of the 2 call sites where this happened). Both sites where this is happening (and not much else?) are inside the stack tree of 0x10fb8ec66 > 0x10fb93947 (in this sample). I'm also attaching the trace.

first call site

and

second call site

I thought this is unnatural, especially because from what I've read about NPAPI, NP_Initialize is meant to be called by the browser only once. So anyone care to venture a suggestion as to why this happens?

I'm using the latest Firefox Beta 20.0 on OSX Mountain Lion 10.8.2, and my version of Shockwave Flash is 11.6.602.167.

Instruments trace at http://www.sendspace.com/file/h12wte

Georg Fritzsche
  • 97,545
  • 26
  • 194
  • 236
Dan
  • 3,490
  • 2
  • 22
  • 27

1 Answers1

2

What you are seeing is an artifact of the way trying to symbolicate a stack from a stripped binary works.

Like most release binaries, Flash is stripped, meaning you don't have any symbol information about the vast majority of the binary. The NP_Initialize symbol, however, has to be exported in order for the plugin to be loaded, so it's one of the few symbols that's present in the binary. The debugger UI is designed for unstripped binaries, and works by looking backward from the actual address to the first function name it can find. In many cases in a release Flash binary, that will be NP_Initialize no matter what the address.

So there's no recursive call, and when it says "NP_Initialize" you should just read that as you would a random hex address: "Some function that I have no idea what it is".

smorgan
  • 20,228
  • 3
  • 47
  • 55
  • Good point - haven't had much experience debugging stripped binaries. Is there any way then to make sense of this stack trace? For instance, disassembling the flash binary and looking up those offsets. Also, looking at the heaviest stack trace I mentioned, other functions in `FlashPlayer-10.6` up the call stack seem to have addresses rather than all being aliased to `NP_Initialize`, how would that be explained? – Dan Feb 25 '13 at 19:01
  • 1
    Sure, you can dump the assembly and read it if you want to, and match address if you have the load offset for the Flash plugin. As for non-(badly-)symbolicated addresses in the binary, all it would take is for them to be earlier in the binary than the first symbol that's present. – smorgan Feb 25 '13 at 19:10