printf uses sbrk, conflicting with custom memory allocator

Question

Hi I have Written a memory allocator, and works perfectly. I use sbrk/brk for page allocation and deallocation. But it all breaks the moment i start printing information using printfs. Googling shows that - printf internally does use sbrk also. So, another glibc function (printf) making use of sbrk modified heap segment unexpectedly - corrupting the bookkeeping the memory allocator is doing.

Reference : sbrk(0) value getting increased after calling printf basically, any other glibc function using sbrk would break my memory allocator. Can you suggest what could be the possible solution to it ?

Pasting the below backtrace showing that printf eventually calls sbrk. Even after printing is done, I see, break pointer never restores to its original point. Shouldnt printf must have restored the break pointer where it was originally in heap segment ? Any alternative to printf in this regard ?

(gdb) bt
0  __GI___sbrk (increment=135168) at sbrk.c:40
1  0x00007ffff7e68a99 in __GI___default_morecore (increment=<optimized out>) at morecore.c:47
2  0x00007ffff7e64297 in sysmalloc (nb=nb@entry=592, av=av@entry=0x7ffff7fb2c40 <main_arena>) at malloc.c:2480
3  0x00007ffff7e657b3 in _int_malloc (av=av@entry=0x7ffff7fb2c40 <main_arena>, bytes=bytes@entry=576) at malloc.c:4149
4  0x00007ffff7e65f25 in tcache_init () at malloc.c:2995
5  0x00007ffff7e66ba6 in tcache_init () at malloc.c:3050
6  __GI___libc_malloc (bytes=1024) at malloc.c:3050
7  0x00007ffff7e4f85c in __GI__IO_file_doallocate (fp=0x7ffff7fb3760 <_IO_2_1_stdout_>) at filedoalloc.c:101
8  0x00007ffff7e5f0b2 in __GI__IO_doallocbuf (fp=fp@entry=0x7ffff7fb3760 <_IO_2_1_stdout_>) at libioP.h:904
9  0x00007ffff7e5e198 in _IO_new_file_overflow (f=0x7ffff7fb3760 <_IO_2_1_stdout_>, ch=-1) at fileops.c:752
10 0x00007ffff7e5cbd5 in _IO_new_file_xsputn (n=13, data=<optimized out>, f=0x7ffff7fb3760 <_IO_2_1_stdout_>) at libioP.h:904
11 _IO_new_file_xsputn (f=0x7ffff7fb3760 <_IO_2_1_stdout_>, data=<optimized out>, n=13) at fileops.c:1204
12 0x00007ffff7e44e10 in __vfprintf_internal (s=0x7ffff7fb3760 <_IO_2_1_stdout_>, format=0x555555557334 "\nPage Size = %zu Bytes\n", ap=ap@entry=0x7fffffffdcc0,
mode_flags=mode_flags@entry=0) at ../libio/libioP.h:904
13 0x00007ffff7e308d8 in __printf (format=<optimized out>) at printf.c:33
14 0x000055555555677d in mm_print_memory_usage () at mm.c:613
15 0x00005555555552a9 in main (argc=1, argv=0x7fffffffdf18) at testapp.c:64

Answer 1

The comment by Ctx:

This is not possible; sbrk() is used by the libc memory allocator internally, so many libc functions use it implicitly. Either do not use libc at all, or do your memory allocations with malloc() or mmap().

is correct. You can only use sbrk if you don't use malloc, and you can't know if you use malloc because unless documented otherwise by the implementation, anything in libc might do so.

If your libc supports replacing malloc (note: most do) then you can write a full malloc replacement (this includes all malloc-family functions, not just malloc itself) that either don't use sbrk, or that cooperate with your use of it, and then you're free to use it. However otherwise, you simply can't use sbrk.

Note also that in some environments, including frequently with position-independent executables (PIE), sbrk will have little or no memory to work with and will frequently fail after only a few allocations or after none at all, because of running into memory mapped for something else. The whole concept of sbrk is backwards and should not be used at all in modern code. For some allocator strategies, it may make sense as one choice of backend, with mmap or something else also used. But it should never be the sole way your allocator obtains new memory, and in my opinion it's not really useful to support it at all. mmap is better in almost all ways.