Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is the first C++ (m)allocation always 72 KB?

joelsiks.com

Post reply on HN
Print view View original

1–10 of 39 posts

Re: Why is the first C++ (m)allocation always 72 KB?

#2

Post by throwaway2037 »

I would like the see the source code for libmymalloc.so, however, I don't see anything in the blog post. Nor do I see anything in his GitHub profile: https://github.com/jsikstro

Also, I cannot find his email address anywhere (to ask him to share it on GitHub).

Am I missing something?

Re: Why is the first C++ (m)allocation always 72 KB?

#3

Post by joelsiks »

throwaway2037 wrote: post #2

I would like the see the source code for libmymalloc.so, however, I don't see anything in the blog post. Nor do I see anything in his GitHub profile: https://github.com/jsikstro Also, I cannot find his email address anywhere (to ask him to share it on GitHub). Am I missing something?

The exact implementation of mymalloc isn't relevant to the post. I have an old allocator published at https://github.com/joelsiks/jsmalloc that I did as part of my Master's thesis, which uses a similar debug-logging mechanism that is described in the post.

Re: Why is the first C++ (m)allocation always 72 KB?

#4

Post by nly »

throwaway2037 wrote: post #2

I would like the see the source code for libmymalloc.so, however, I don't see anything in the blog post. Nor do I see anything in his GitHub profile: https://github.com/jsikstro Also, I cannot find his email address anywhere (to ask him to share it on GitHub). Am I missing something?

dlsym() with the RTLD_NEXT flag basically:

https://catonmat.net/simple-ld-preload-tutorial-part-two

There's actually a better way to hook GNUs malloc:

https://www.man7.org/linux/man-pages/man3/malloc_hook.3.html

This is better because you can disable the hook inside the callback, and therefore use malloc within your malloc hook (no recursion)

But you can't use this mechanism before main()

Re: Why is the first C++ (m)allocation always 72 KB?

#5

Post by Joker_vD »

nly wrote: post #4
throwaway2037 wrote: post #2

I would like the see the source code for libmymalloc.so, however, I don't see anything in the blog post. Nor do I see anything in his GitHub profile: https://github.com/jsikstro Also, I cannot find his email address anywhere (to ask him to share it on GitHub). Am I missing something?

dlsym() with the RTLD_NEXT flag basically: https://catonmat.net/simple-ld-preload-tutorial-part-two There's actually a better way to hook GNUs malloc: https://www.man7.org/linux/man-pages/man3/malloc_hook.3.html This is better because you can disable the hook inside the callback, and therefore use malloc within your malloc hook (no recursion) But you can't use this mechanism before main()

    The use of these hook functions is not safe in multithreaded
    programs, and they are now deprecated.  From glibc 2.24 onwards,
    the __malloc_initialize_hook variable has been removed from the
    API, and from glibc 2.34 onwards, all the hook variables have been
    removed from the API.  Programmers should instead preempt calls to
    the relevant functions by defining and exporting malloc(), free(),
    realloc(), and calloc().

Re: Why is the first C++ (m)allocation always 72 KB?

#7

Post by joelsiks »

Joker_vD wrote: post #6

Huh. Why is this emergency pool not statically allocated? Is it possible to tune the size of this pool on libc++ startup somehow? Because otherwise it absolutely should've been statically allocated.

I did mention it briefly in the post, but you can opt-in for a fixed-size statically allocated buffer by configuring libstdc++ with --enable-libstdcxx-static-eh-pool. Also, you can opt-out of the pool entirely by configuring the number of objects in the pool to zero with the environment variable GLIBCXX_TUNABLES=glibcxx.eh_pool.obj_count=0.

Re: Why is the first C++ (m)allocation always 72 KB?

#8

Post by nly »

Joker_vD wrote: post #5
nly wrote: post #4

Earlier quoted context omitted.

dlsym() with the RTLD_NEXT flag basically: https://catonmat.net/simple-ld-preload-tutorial-part-two There's actually a better way to hook GNUs malloc: https://www.man7.org/linux/man-pages/man3/malloc_hook.3.html This is better because you can disable the hook inside the callback, and therefore use malloc within your malloc hook (no recursion) But you can't use this mechanism before main()

The use of these hook functions is not safe in multithreaded programs, and they are now deprecated. From glibc 2.24 onwards, the __malloc_initialize_hook variable has been removed from the API, and from glibc 2.34 onwards, all the hook variables have been removed from the API. Programmers should instead preempt calls to the relevant functions by defining and exporting malloc(), free(), realloc(), and calloc().

Yeah. Shame though because it gave you the option to control exactly when you hooked and didn't hook, which let stop and start debugging allocations based on arbitrary triggers.

The global variable approach was very useful and pretty low overhead.

Post reply on HN