Why using both malloc/calloc/realloc and brk functions will results in undefined behavior?

Question

Does this means using one of (malloc or calloc or realloc) and one of(brk/sbrk) concurrently results in UB or using both malloc and calloc can also cause UB?

This happends through the entire program or just a source file?

Answer 1

The actual rule, on systems that have both sbrk and malloc, is "The implementation of malloc may assume that no code other than itself calls sbrk with a nonzero argument."

Phrased this way, the consequences are much easier to deduce:

• There must be only one operational implementation of malloc per process. (On systems like this, the OS-provided C library's malloc is usually designed to notice and gracefully step aside when you supply another implementation.)

• It is fine to call sbrk(0) anywhere you want.

• If you are writing an implementation of malloc, you may go right ahead and call sbrk with a nonzero argument, and assume that nobody else will.

• But if you are not writing an implementation of malloc, calling sbrk with a nonzero argument will probably cause the next call to malloc (or any function that calls malloc internally, which could be any of them except those documented as async-signal-safe) to crash the process or corrupt the heap.

  It should be easy to see why calling sbrk with a negative argument, from outside the malloc implementation, can have this effect. You shrank the heap! There might have been allocations in the space that you took away! There almost certainly are internal malloc bookkeeping structures in there!

  Why calling sbrk with a positive argument can have the same effect is more subtle. malloc won't know about the additional space. The next time malloc calls sbrk itself, it will update its internal bookkeeping structures incorrectly. There will be a chunk of memory in the middle of the heap that it's not able to track. It's very likely to scribble on that memory and/or confuse itself into accessing addresses outside the heap.