2

I was using perf on a profiling work. But I got some problems:

  1. a lot of weird output memory addresses
  2. there is some addresses from user not translate to symbols

I compiled the problem with -fno-omit-frame-pointer ... and -g, but still got this problem.

Can anyone help to have a look? How to fix these two problems?

The perf output is:

 9.28%  gserver  gserver     [.] 0x000000000013bb20

 2.36%  gserver  libpthread-2.19.so  [.] pthread_mutex_lock
        |
        --- pthread_mutex_lock
           |
           |--28.31%-- 0x0
           |          |
           |          |--38.16%-- 0x3
           |          |
           |          |--37.72%-- 0x0
           |          |          |
           |          |          |--90.05%-- 0x25
           |          |          |          |
           |          |          |          |--53.41%-- 0x100000001
           |          |          |          |          std::_Sp_counted_ptr<Buffer*, (__gnu_cxx::_Lock_policy)2>::~_Sp_counted_ptr()
           |          |          |          |          0x1f0fc35de58948
osgx
  • 90,338
  • 53
  • 357
  • 513
zuanyg
  • 71
  • 1
  • 1
  • 5

1 Answers1

1

It doesn't matter, because those are in library code, which you didn't build, and you can't fix.

You can see it's spending 2.63% of its time in a mutex_lock, meaning it's waiting for something.
That's insignificant.

I assume you're looking for significant stuff. I use this technique.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • How the (patented) "this technique" may help to resolve unknown memory addresses? `gserver` is not the library and address of 0x13bb20 sounds like executable ELF address, not library address. It is some problem inside perf program, not in profiling method. – osgx May 31 '17 at 18:35
  • @osgx: Patented? Anyway, my point is, people generally do performance tuning because they want to make something faster. To do that, it has to be code they can modify. So if they see that line A of their code is calling library function B 50% of the time, all the information they need is in line A of their code (and the stack trace of their code leading to line A). Gobs of time can be spent in libraries, but how does it help to know that? – Mike Dunlavey May 31 '17 at 23:49