What does the brk() system call do?

by

In the diagram you posted, the “break”—the address manipulated by brk and sbrk—is the dotted line at the top of the heap.

simplified image of virtual memory layout

The documentation you’ve read describes this as the end of the “data segment” because in traditional (pre-shared-libraries, pre-mmap) Unix the data segment was continuous with the heap; before program start, the kernel would load the “text” and “data” blocks into RAM starting at address zero (actually a little above address zero, so that the NULL pointer genuinely didn’t point to anything) and set the break address to the end of the data segment. The first call to malloc would then use sbrk to move the break up and create the heap in between the top of the data segment and the new, higher break address, as shown in the diagram, and subsequent use of malloc would use it to make the heap bigger as necessary.

Meantime, the stack starts at the top of memory and grows down. The stack doesn’t need explicit system calls to make it bigger; either it starts off with as much RAM allocated to it as it can ever have (this was the traditional approach) or there is a region of reserved addresses below the stack, to which the kernel automatically allocates RAM when it notices an attempt to write there (this is the modern approach). Either way, there may or may not be a “guard” region at the bottom of the address space that can be used for stack. If this region exists (all modern systems do this) it is permanently unmapped; if either the stack or the heap tries to grow into it, you get a segmentation fault. Traditionally, though, the kernel made no attempt to enforce a boundary; the stack could grow into the heap, or the heap could grow into the stack, and either way they would scribble over each other’s data and the program would crash. If you were very lucky it would crash immediately.

I’m not sure where the number 512GB in this diagram comes from. It implies a 64-bit virtual address space, which is inconsistent with the very simple memory map you have there. A real 64-bit address space looks more like this:

less simplified address space

              Legend:  t: text, d: data, b: BSS

This is not remotely to scale, and it shouldn’t be interpreted as exactly how any given OS does stuff (after I drew it I discovered that Linux actually puts the executable much closer to address zero than I thought it did, and the shared libraries at surprisingly high addresses). The black regions of this diagram are unmapped — any access causes an immediate segfault — and they are gigantic relative to the gray areas. The light-gray regions are the program and its shared libraries (there can be dozens of shared libraries); each has an independent text and data segment (and “bss” segment, which also contains global data but is initialized to all-bits-zero rather than taking up space in the executable or library on disk). The heap is no longer necessarily continous with the executable’s data segment — I drew it that way, but it looks like Linux, at least, doesn’t do that. The stack is no longer pegged to the top of the virtual address space, and the distance between the heap and the stack is so enormous that you don’t have to worry about crossing it.

The break is still the upper limit of the heap. However, what I didn’t show is that there could be dozens of independent allocations of memory off there in the black somewhere, made with mmap instead of brk. (The OS will try to keep these far away from the brk area so they don’t collide.)

More Related Contents:

  1. printf anomaly after “fork()”
  2. How to make child process die after parent exits?
  3. Why is malloc not “using up” the memory on my computer?
  4. How to capture Control+D signal?
  5. Why does this program print “forked!” 4 times?
  6. In C how do you redirect stdin/stdout/stderr to files when making an execvp() or similar call?
  7. stdout thread-safe in C on Linux?
  8. Why does ENOENT mean “No such file or directory”?
  9. Merge multiple .so shared libraries
  10. Re-opening stdout and stdin file descriptors after closing them
  11. Turn a simple socket into an SSL socket
  12. How do I get a thread ID from an arbitrary pthread_t?
  13. Are there any platforms where using structure copy on an fd_set (for select() or pselect()) causes problems?
  14. How can I convert a file pointer ( FILE* fp ) to a file descriptor (int fd)?
  15. After forking, are global variables shared?
  16. Set environment variables in C
  17. Are file descriptors shared when fork()ing?
  18. Detecting 64bit compile in C
  19. Memory usage of current process in C
  20. fd leak, custom Shell
  21. Force free() to return malloc memory back to OS
  22. Questions about putenv() and setenv()
  23. In C, what’s the size of stdout buffer?
  24. What can cause a “Resource temporarily unavailable” on sock send() command
  25. /proc/[pid]/pagemaps and /proc/[pid]/maps | linux
  26. How to open, read, and write from serial port in C?
  27. How to set CPU affinity for a process from C or C++ in Linux?
  28. How to detect key presses in a Linux C GUI program without prompting the user?
  29. Returning struct containing array
  30. Efficient way to find task_struct by pid

Leave a Comment