Closed GoogleCodeExporter closed 9 years ago
Thanks for the report. I would like to understand this better; I wouldn't
think ASLR should be a problem for us, as I understand how ASLR works (which is
probably not very well). It randomizes the base address for each shared
library loaded into memory, right? But the correct address is still returned
by /proc/self/maps (or whatever the OS X equivalent is)? That information is
stored in the heap-sample output, so should let us proceed ok.
Or maybe the correct address isn't returned by /proc/self/maps; I could find
surprisingly little on the web about how ASLR is actually implemented.
I'd love a solution that lets tcmalloc work with aslr, since all OSes are
getting it. I guess telling people they have to disable ASLR to do profiling
isn't the end of the world -- they can still compile the final binary normally
-- but it's not ideal.
Original comment by csilv...@gmail.com
on 3 Aug 2011 at 12:15
Hi again,
I think vmmap is the OS X equivalent of /proc/self/map
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/
man1/vmmap.1.html
Not sure if my case is special because of using
MallocExtension::instance()->GetHeapSample() rather than HEAPPROFILE and log
output. Basically I'm dumping the output of GetHeapSample on to a URL for
realtime profiling.
Will read the code tomorrow and report back any thoughts. Definitely agree the
less gcc flags, the better!
Donovan.
Original comment by DonovanH...@gmail.com
on 3 Aug 2011 at 12:52
It looks like we actually use dyld_get_image_header() and iterate through that.
You can see in src/base/sysinfo.cc.
My guess is you'll want to expose the maps info via a url the same way as the
GetHeapSample() data. c.f. docs/pprof_remote_servers.html. If you set up your
server as the doc suggests, you can get realtime information directly via
pprof! (Maybe that's what you're doing already.)
pprof myserver:port/pprof/heap
The hard part -- the part that I think is missing for you now -- is the
/pprof/symbol support.
Original comment by csilv...@gmail.com
on 3 Aug 2011 at 1:31
Haven't heard anything in a while, so closing. I think this ended up being not
a bug for normal use of perftools, but if that's not the case, feel free to
reopen.
Original comment by csilv...@gmail.com
on 18 Oct 2011 at 6:46
Hi,
Can you elaborate how this is 'not a bug for normal use of perftools'? Do you
mean that is not relevant to Google's normal use, or other people's normal use?
As one of the 'other people' who would like to use this, it really does render
Goole Performance Tools mostly unusable on OSX for default compilation options.
Thanks,
Travis
Original comment by travi...@traviscj.com
on 19 Sep 2013 at 2:32
Surely "a normal use of perftools" might include any use of pprof and the other
tools in Mac OS X?
Original comment by denpasho...@gmail.com
on 21 Jan 2015 at 3:48
Original issue reported on code.google.com by
DonovanH...@gmail.com
on 2 Aug 2011 at 11:39