Unable to attach process for Hotspots analysis

[duanetiemann]

I currently have an evaluation copy of VTune for Linux (build 139491) .

It looked like I should be able to attach a process for Hotspots analysis, but when I tried it in the GUI I got "This analysis type doesn't support system-wide profiling or attaching to a process. Please specify an application to launch." As I recall, this also happened from the command line, but I don't have that data close to hand.

In the initial Hotspots screen it says "This analysys type cannot be used to profile the system but must either launch an application/process or attach to one".

I did manage to set up all our env variables and tried to lauch our product as an application, but it somehow failed to launch that way. So far I haven't been able to figure that out. For now, I'd like to just attach to it if that is possible.

Thanks, Duane

[David_A_Intel1]

Hi Duane:

Please download the latest release, Update 3 (build 150226), for support of attaching to a process. Update 3 was recently released and added support for attaching to a process for hotspots analysis on Linux. Support was already there for Windows (starting with Update 2, build 139491).

You may also be interested in this post related to attaching on Linux.

[duanetiemann]

Thanks. That got me past the error message.
Now my problem is thatour app crashes when I start Hotspot analysis on it.
I tried it twice.
Looks like we're in clib ptmalloc. Our app uses a tweaked version of ptmalloc instead. Is that the problem?Do you insert a thread in our process to do the stack traces andsomehow get some malloc crosstalk?

Thanks, Duane

Program terminated with signal 8, Arithmetic exception.
#0 0x0000003effa6f0bc in sYSTRIm () from /lib64/libc.so.6
(gdb) where
#0 0x0000003effa6f0bc in sYSTRIm () from /lib64/libc.so.6
#1 0x0000003effa71453 in _int_free () from /lib64/libc.so.6
#2 0x0000003effa74c5c in free () from /lib64/libc.so.6
#3 0x00002aaacd514591 in ?? ()
#4 0x0000000000000060 in ?? ()
#5 0x00002aaacd4e4e8b in ?? ()
#6 0x00002aaaf02d1df0 in ?? ()
#7 0x00002aaaec202be0 in ?? ()
#8 0x00002aaaec202c20 in ?? ()
#9 0x00002aaaec202bc0 in ?? ()
#10 0x00002aaaec202c00 in ?? ()
#11 0x0000003effd4e9a0 in __after_morecore_hook () from /lib64/libc.so.6
#12 0x00002aaaf06d5ff0 in ?? ()
#13 0x00002aaaf06d8010 in ?? ()
#14 0x00002aaacd4e2800 in ?? ()
#15 0x0000000000000021 in ?? ()
#16 0x00002aaacd9bc800 in ?? ()
#17 0x0000003effa74c5c in free () from /lib64/libc.so.6
#18 0x00002aaacd4e2782 in ?? ()
#19 0x0000000000000000 in ?? ()
(gdb) thread
[Current thread is 1 (process 24725)]

[David_A_Intel1]

Hi Duane:

Does your library export malloc() and free()? Or, does the app call malloc and free, as well as the "tweaked" ptmalloc?

Currently, since our collector runs within your process, and we use malloc/free, if your process loads a non-standard malloc and free, it could cause problems. You can test this theory out by defining the following environment variable:

$ export MALLOC_CHEK_=0

and running amplxe from that shell, which would then launch your app.

[duanetiemann]

We use the tweaked ptmalloc exclusively. It is in a library which does export malloc and free. We do not LD_PRELOAD it but AFAIK everything in our process (except you) uses the tweaked version.

I tried launching with the MALLOC_CHECK=0 but nothing significant seemed to happen. Our app apparently just went away without a whimper as before.

[duanetiemann]

I tried LD_PRELOADing our ptmalloc, but got the same result.
I then tried LD_PRELOADing /lib64/libc.so.6 (which contains the stock ptmalloc). That worked.

I'll continue doing that for now. It looks like we cannot use VTune and our tweaked ptmalloc together without taking extreme measures (e.g. mess with libc.so.6).

[duanetiemann]

I tried LD_PRELOADing our ptmalloc, but got the same result.
I then tried LD_PRELOADing /lib64/libc.so.6 (which contains the stock ptmalloc). That worked.

I'll continue doing that for now. It looks like we cannot use VTune and our tweaked ptmalloc together without taking extreme measures (e.g. mess with libc.so.6).

[David_A_Intel1]

It looks like we both made a typo wrt the environment variable. I dropped a C and you dropped the trailing underscore. The correct variable is MALLOC_CHECK_=0. Please notice the trailing underscore. So, you can either do what you are doing with LD_PRELOAD or try this variable, again.

Yes, we are looking at a general solution to this problem. I'll try to remember to update this thread when/if it is available.

[duanetiemann]

Thanks. The MALLOC_CHECK_ does work. But then I notice that we spend all our time in malloc_check, realloc_check, etc.

When I run with the LD_PRELOAD to the stock ptmalloc, I notice that I get stack fragments in the report. pthread_cond_signal and _int_free, etc. will be alone at the top of the Top-down Tree. That doesn't seem right. And, of course, we see characteristics of the stock malloc that we tweaked to get out of e.g. replicated spikes in the arenas.

BTW, This is from update 4.