How to free memory from sys_brk (64-bit)?

Index > Linux > How to free memory from sys_brk (64-bit)?

Author

Thread

fasmnewbie

Joined: 01 Mar 2011
Posts: 555

fasmnewbie 23 Feb 2016, 04:20

Not sure if this is the right question to ask but I can't find any syscall that can free memory block allocated by sys_brk. Should I just leave it die out along with exit code or will it stay there, hence a leak? Will re-invoking another sys_brk with negative or 0 (in rdi) 'free' the allocated block? Thanks in advance for your answers.

23 Feb 2016, 04:20

JohnFound

Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria

JohnFound 23 Feb 2016, 04:49

After the exit of the application, all memory is returned to the system. No leaks at all.

But you can free the memory allocated by sys_brk, for example for long living application, when you don't need this memory anymore.

Simply call again sys_brk with EBX smaller than on the first call. Notice that the value in EBX is not the size of the memory, but the upper address of the uninitialized data segment of the program.

Also, you must know that after the call to sys_brk, the memory is not actually allocated. It will be allocated on page basis only after the first memory access operation.

23 Feb 2016, 04:49

fasmnewbie

Joined: 01 Mar 2011
Posts: 555

fasmnewbie 23 Feb 2016, 05:01

JohnFound wrote:

Simply call again sys_brk with EBX smaller than on the first call. Notice that the value in EBX is not the size of the memory, but the upper address of the uninitialized data segment of the program.

I think that should do it. But now I am having problem with the error code. For example if I attempt to free the memory (not yet allocated), RAX still shows a 'valid' address. I don't know where to pick up the error code except in RCX where it is -1 (but I don't think this value shows any error code).

23 Feb 2016, 05:01

fasmnewbie

Joined: 01 Mar 2011
Posts: 555

fasmnewbie 23 Feb 2016, 05:08

JohnFound wrote:

It will be allocated on page basis only after the first memory access operation.

Page? Do I need to manually set the alignment here or is it aligned by default by sys_brk?

23 Feb 2016, 05:08

fasmnewbie

Joined: 01 Mar 2011
Posts: 555

fasmnewbie 23 Feb 2016, 05:14

John you are from bulgaria? Wasn't it you who hacked the Linux Mint download site? Run Forrest, ruunn!!

23 Feb 2016, 05:14

JohnFound

Joined: 16 Jun 2003
Posts: 3499
Location: Bulgaria

JohnFound 23 Feb 2016, 06:42

I don't like where Linux Mint goes and migrated to Manjaro Linux. But, no, I didn't hacked Linux Mint servers. Very Happy

sys_brk does not actually allocate memory. It allocates address space for your program. Once allocated, you can access this address space. On first access to some address in this space, exception will arise and the exception handler in the kernel will allocate one page of memory where this address belongs and will return the control to your program. This all process is fully transparent for the application. Only small delay will happen on the first access to every page (regardless of where inside the page you try to read/write).

23 Feb 2016, 06:42

redsock

Joined: 09 Oct 2009
Posts: 434
Location: Australia

redsock 23 Feb 2016, 22:10

FWIW, deallocation via brk works too, though I particularly like the Mac OS X manpage for brk:

Quote:

The brk and sbrk functions are historical curiosities left over from earlier days before the advent of virtual memory management.

Of course I agree with JohnFound re: memory always being returned to the OS, I wrote a quick demonstration of returning memory via brk included below.

All of my linux goods use mmap with MAP_PRIVATE which accomplishes memory management (similar to how all of the malloc libraries do it anyway, though some will still use brk for small allocations early-on).

AFAIK the program break will always initially be aligned 16 on x86_64, but this is not something I have verified.

Cheers

Code:

        format ELF64

public _start
_start:
        ; get current value of the program break:
        mov     eax, 12         ; syscall brk
        xor     edi, edi        ; 0
        syscall

        mov     rbx, rax        ; save it

        ; increase by 32MB
        mov     eax, 12
        lea     rdi, [rbx+33554432]
        syscall

        int3                    ; breakpoint to observe return value in rax
        nop

        ; lower it by 16MB
        mov     eax, 12
        lea     rdi, [rbx+16777216]
        syscall

        int3                    ; observe again
        nop

        mov     eax, 60         ; exit
        xor     edi, edi        ; return code
        syscall

23 Feb 2016, 22:10

fasmnewbie

Joined: 01 Mar 2011
Posts: 555

fasmnewbie 08 Mar 2016, 05:25

redsock

thanks for the answer. I been reading comments discouraging people from using brk and to use mmap or malloc instead. The reason is because of it being used by malloc and to some extend, mmap, giving me this scary impression that sys_brk is too fragile to handle naked. Any idea how and under what circumstances that sys_brk would in anyway be affected by malloc and mmap? AFAIK, whether it is used by malloc, mmap or multiple sys_brk, it will always issue a valid pointer (or none if fail) as per request and I don't see any reason they should interfere with each other. Appreciate your answers.

08 Mar 2016, 05:25

fasmnewbie

Joined: 01 Mar 2011
Posts: 555

fasmnewbie 08 Mar 2016, 05:36

Quote:

program break will always initially be aligned 16 on x86_64, but this is not something I have verified.

I tested on both Win64 (malloc) and Linux64 (sys_brk). The pointers always returned align to 16.... so far.

08 Mar 2016, 05:36

redsock

Joined: 09 Oct 2009
Posts: 434
Location: Australia

redsock 09 Mar 2016, 00:34

fasmnewbie wrote:

Any idea how and under what circumstances that sys_brk would in anyway be affected by malloc and mmap? AFAIK, whether it is used by malloc, mmap or multiple sys_brk, it will always issue a valid pointer (or none if fail) as per request and I don't see any reason they should interfere with each other. Appreciate your answers.

Unless the malloc library/implementation is "naive" and treats it all as a contiguous block, there really isn't likely to be any problems. Specifically, if your user code acquires a block of new memory (and measures said block from the current program break to the new break), and then malloc comes along and increases the program break but does not treat it as a new "block" but instead attempts to use the entire region, or vice versa of course, there'd be problems.

Allocating memory via mmap only requires extra arguments and is a "cleaner" way to do it IMO.

_________________
2 Ton Digital - https://2ton.com.au/

09 Mar 2016, 00:34

fasmnewbie

Joined: 01 Mar 2011
Posts: 555

fasmnewbie 11 Mar 2016, 14:29

redsock wrote:

fasmnewbie wrote:
Any idea how and under what circumstances that sys_brk would in anyway be affected by malloc and mmap? AFAIK, whether it is used by malloc, mmap or multiple sys_brk, it will always issue a valid pointer (or none if fail) as per request and I don't see any reason they should interfere with each other. Appreciate your answers.
Unless the malloc library/implementation is "naive" and treats it all as a contiguous block, there really isn't likely to be any problems. Specifically, if your user code acquires a block of new memory (and measures said block from the current program break to the new break), and then malloc comes along and increases the program break but does not treat it as a new "block" but instead attempts to use the entire region, or vice versa of course, there'd be problems.

Allocating memory via mmap only requires extra arguments and is a "cleaner" way to do it IMO.

Thanks for the explanation. That means I'd be in trouble if I mix my primitive library with C's.

11 Mar 2016, 14:29

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum