How do I free memory obtained by sbrk()?

Question

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 ?

Ellyellyn

Answer 1

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.

Precaution

-1, you can decrease with sbrk, just pass it a negative value. – Woolard

You are right, I'll edit it. Never used sbrk like that, cool. – Precaution

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. – Beadledom

@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. – Stinkhorn

@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. – Beadledom

@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 ! – Stinkhorn

Answer 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.

Unselfish

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). – Stinkhorn

@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. – Unselfish

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 ? – Stinkhorn

@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). – Unselfish

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. – Stinkhorn

@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. – Unselfish