function names not appearing in case of encrypted so on Linux

[GoogleCodeExporter]

What steps will reproduce the problem?
1. run google profiler on a executable which has encrypted so, which are 
decrypted in /tmp and deleted at the end of the executable
2. the last of the profiler shows something like this
2aa695f000-2aa6970000 r-xp 00000000 00:00 2899        /tmp/spyauth21745831539 
(deleted)
2aa6970000-2aa6a70000 ---p 00011000 00:00 2899        /tmp/spyauth21745831539 
(deleted)
2aa6a70000-2aa6a71000 rw-p 00011000 00:00 2899        /tmp/spyauth21745831539 
(deleted)

3. all the function in this are given out as function pointers instead of 
function names.

What is the expected output? What do you see instead?
we should see the function names

What version of the product are you using? On what operating system?
1.9

Please provide any additional information below.
all the function names in the encrypted so are shows as function pointers. this 
may be by design as at the end of the executable the profiler might me looking 
up the function names and at that point the so is deleted.

Original issue reported on code.google.com by anshulkr on 30 Jan 2012 at 4:56

[GoogleCodeExporter]

Yes, perftools won't work against an encypted so, since pprof tries to read 
symbols from the .so separately from the program being run.  You will need some 
way to provide the symbols directly to pprof, perhaps by creating a data file 
similar to the one used in --raw mode.

I'll leave the bug open for now, but lower its priority since this seems like a 
pretty rare case, and possibly working correctly as designed: I doubt anyone 
using encrypted .so's *wants* someone like pprof to be able to see the 
unencrypted symbol names.

Original comment by csilv...@gmail.com on 30 Jan 2012 at 10:34

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

The .so are not encrypted. the tool takes in some encrypted .so
and decrypts them into the /tmp. they are then opened through dlopen.

at the end of the run they are removed from the /tmp file system and hence
the message in the end of the file that I have pasted in the bug.

Further, I tried yesterday with the 'profileStart()' and 'profileEnd()', at
which point all the .so would already have been in the /tmp and opened. and
in the map section of the output file they do not come as deleted. Still I
do not get the function name and only the functions pointers.

Could this be due to dlopen?

-Anshul

Original comment by anshulkr on 31 Jan 2012 at 4:00

[GoogleCodeExporter]

One of us is misunderstanding the control flow here.  Please state the *exact* 
set of steps you ran, and the output of each.

Original comment by csilv...@gmail.com on 31 Jan 2012 at 5:40

[GoogleCodeExporter]

I have figured out where the problem is but here is the flow:

there is a binary which dlopens a .so and de-encrypts it in to a file in /tmp 
area.

now we start profiling

at the end of the binary we will delete the de-encrypted .so from the /tmp

in the output file of the profiler there are paths to the files in the /tmp 
which is needs to do addr2line to figure out the function name. At this point 
of time the .so is not present in the /tmp hence the function pointers.

I have manually gone and replaces the /tmp paths in the output file to the 
standard non-encrypted .so and every this works as expected. 

It is an issue with out use model and looks like we need to write wrapper 
scripts to take care of such issues. 

Original comment by anshulkr on 1 Feb 2012 at 8:09

[GoogleCodeExporter]

how can i close this issue? 

Original comment by anshulkr on 1 Feb 2012 at 8:10

[GoogleCodeExporter]

No problem, I'll close it.  Glad you figured it out!

Original comment by csilv...@gmail.com on 1 Feb 2012 at 6:33

• Changed state: Invalid