17

I have a custom allocator function which uses sbrk() to obtain memory. How do I release this memory when it's no longer needed?

Is there a function equivalent to free() for malloc() ?

or do I have to use brk() to set the end of the data segment ?

user238707
  • 205
  • 1
  • 2
  • 6

2 Answers2

30

You need to use brk or sbrk again to shrink.

In the end the only way you have to modify the amount of memory(apart from mmap like syscalls), is to increase or decrease the heap, so you move it up with sbrk or brk and you move it down with brk or sbrk with a negative increment.

Arkaitz Jimenez
  • 22,500
  • 11
  • 75
  • 105
  • 7
    -1, you can decrease with `sbrk`, just pass it a negative value. – avakar Jan 12 '10 at 20:27
  • 1
    You are right, I'll edit it. Never used sbrk like that, cool. – Arkaitz Jimenez Jan 12 '10 at 20:30
  • 2
    The only thing to worry about is whether something other than your code called 'sbrk()' and got memory and that your adjustment downwards invalidates memory that something else is still using. – Jonathan Leffler Jan 12 '10 at 22:24
  • @JonathanLeffler: this is why memory allocation is centralized (by malloc in a typical C-run time or C++ run time). And all accesses are mutexed because of that centralization. glibc will even detect thread contention and create thread specific heap pools on the fly. But all calls to sbrk are filtered by this CRT layer so it is well managed. If you use sbrk yourself you've got to sync yourself with other users, or know/make sure that there are no other users. – v.oddou Jun 16 '14 at 04:02
  • @v.oddou: Since the question is about a custom allocator (not stated to be a replacement for `malloc()` et al), your comments are rather tangential to the problem. Clearly, in this context, memory allocation is not being centralized by the run-time library. – Jonathan Leffler Jun 16 '14 at 04:08
  • @JonathanLeffler: Well I didn't say that your comment was off the hook at all. I merely added a nuance to it (which actually goes in your direction). Now, about the OP question, it says nothing, that is true. Therefore I assumed the opposite of what you assumed, that he know what he was up against ! – v.oddou Jun 16 '14 at 04:15
2

Don't use brk and sbrk. It's pretty much impossible to know which library functions might call malloc, and could change over time, so even if your program works now, it might break when somebody upgrades libc. They were excluded from POSIX for a very good reason.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • 8
    who said his allocator is not the only thing used to allocate from heap in his process/application ? it might be perfectly legit. Please refrain from just stating some absolute "do and dont's" like if you knew better for everyone in every cases. Your explanation is perfect but it also says why you are wrong (case he doesnt use malloc). – v.oddou Jun 16 '14 at 03:59
  • 3
    @v.oddou: How does he know `printf` doesn't use `malloc`? (On many real systems, it does!) Or any other standard library function? That was the whole point of my answer. "I don't use `malloc`" is not a sufficient condition for `brk` or `sbrk` to be safe to use. Really *there is no sufficient condition* for them to be safe. – R.. GitHub STOP HELPING ICE Jun 16 '14 at 04:07
  • very good point. that will serve some mediation for users of `sbrk`. Now, what if one doesn't use any stdlib at all ? or better, a custom stdlib that specifically doesnt use malloc. OR EVEN, a hooked runtime that hacks the malloc function by doing some virtual symbol table redirection into a custom function ? – v.oddou Jun 16 '14 at 04:12
  • 1
    @v.oddou: All of those are really outside the scope of using the C language and into the scope of (re)writing part or all of the implementation, in which case there may be a way to use `sbrk` safely. In fact I would surmise that the only reason `sbrk` is still offered on many modern systems is as a tool for writing custom versions of `malloc`, and if that's supported by your system, it's probably the one usage case in which `sbrk` is safe (since you can't fight with `malloc` if you're the one providing `malloc`). – R.. GitHub STOP HELPING ICE Jun 16 '14 at 04:15
  • 2
    very well, so it seems we agree perfectly in the end. Who says OP is not writing his allocator, and providing it IN the `malloc` itself ? which as you say, is legit. So you see "dont't use brk" in your original statement is just too strong. – v.oddou Jun 16 '14 at 04:18
  • 2
    @v.oddou: It's not clear from the question whether "custom allocator" means "replacement implementation of `malloc`" or something used in place of `malloc` but with a different name and API. In the former case it's probably ok; in the latter it's definitely not. – R.. GitHub STOP HELPING ICE Jun 16 '14 at 04:39