-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Profiling mmap
on macOS not working
#1458
Comments
Correct. We don't have working mmap interception on this platform. Feel free to contribute. Here are the typical "sane" options: a) define mmap/munmap and syscall directly bypassing libc's implementation. We do that on Linux and FreeBSD. Lately I saw OSX headers bark on syscall usage claiming it is deprecated. So maybe less of an option for OSX (or not, I'd check what they suggest). b) define mmap/munmap and use dlsym with RTLD_NEXT to find OS's original mmap/munmap implementation. AFAIR previous FreeBSD mmap hooking implementation used that. Requires dynamic linking but perhaps that is already mandatory for your OS ? c) sometimes libcs deliberately implement _mmap or something like that and mmap is just alias (the case for GNU libc). We then define our mmap with hooking functionality that eventually calls _mmap for actual mapping syscall. On top of that there are some less sane options (like code patching and whatnot). Good luck. |
@alk Thanks for the clarification. I wasn't aware of that limitation on macOS (did I overlook some statements in the official documentation? ). If I find time I may look into your suggestions for contribution regarding the issue. Right now I try using gperftools to measure memory usage for a scheduled project, so investigating the issue is no option (right now) for me. But just to be clear: If I was using Linux or (Free)BSD, my MWE would work as extected? In that case I might switch the platform for my current project. Again, thanks for the quick and informative answer. That really helped me so far. |
FreeBSD and Linux should work, but note that we currently don't have mmap profiling test coverage. Another thing to keep in mind is issue #1128. That is both glibc and musl invoke internal "version" of mmap when mapping thread stacks, so we're unable to intercept those. |
So I am about to drop mmap profiling entirely (it'll land after 2.16rc becomes 2.16). And thus I am going to close this ticket as wont-fix. |
Problem
The heap profiler does not track
mmap
calls, even if environment variableHEAP_PROFILE_MMAP
is set.Environment
36fa5ee9
(build from source)Minimal working example
foo.cpp
CMakeLists.txt
Steps to reproduce
Run
./build/foo
binary as following:Results
malloc
was used for alloction the output says "Exiting, 44 kB in use", which seems correct.mmap
was used for allocation the output says "Exiting, 4 kB in use", which seems does not recognized the manually allocated memory. (4 kB seem to come from theprintf
call).$ head foo.0001.heap
(malloc)$ head foo.0001.heap
(mmap)Question
What exactly am I doing wrong? It seem my test program work correct. Linking seems to be correct, otherwise there should be no memory dump at all. The
HEAP_PROFILE_MMAP
seem to be correct according to the docs andtrue
as enabling value seem to be correct according to source.The text was updated successfully, but these errors were encountered: