/share/doc/papers/malloc/problems.ms

 1.\"
 2.\" ----------------------------------------------------------------------------
 3.\" "THE BEER-WARE LICENSE" (Revision 42):
 4.\" <phk@FreeBSD.org> wrote this file.  As long as you retain this notice you
 5.\" can do whatever you want with this stuff. If we meet some day, and you think
 6.\" this stuff is worth it, you can buy me a beer in return.   Poul-Henning Kamp
 7.\" ----------------------------------------------------------------------------
 8.\"
 9.\" $FreeBSD$
10.\"
11.ds RH The problems
12.NH
13The problems
14.PP
15Even though malloc(3) is a lot simpler to use
16than the raw brk(2)/sbrk(2) interface,
17or maybe exactly because
18of that,
19a lot of problems arise from its use.
20.IP
21Writing to memory outside the allocated chunk.
22The most likely result being that the data structure used to hold
23the links and flags about this chunk or the next one gets thrashed.
24.IP
25Freeing a pointer to memory not allocated by malloc.
26This is often a pointer that points to an object on the stack or in the
27data-section, in newer implementations of C it may even be in the text-
28section where it is likely to be readonly.
29Some malloc implementations detect this, some don't.
30.IP
31Freeing a modified pointer.  This is a very common mistake, freeing
32not the pointer malloc(3) returned, but rather some offset from it.
33Some mallocs will handle this correctly if the offset is positive.
34.IP
35Freeing the same pointer more than once.
36.IP
37Accessing memory in a chunk after it has been free(3)'ed.
38.PP
39The handling of these problems have traditionally been weak.
40A core-dump was the most common form for "handling", but in rare
41cases one could experience the famous "malloc: corrupt arena." 
42message before the core-dump.
43Even worse though, very often the program will just continue,
44possibly giving wrong results.
45.PP
46An entirely different form of problem is that
47the memory returned by malloc(3) can contain any value.
48Unfortunately most kernels, correctly, zero out the storage they 
49provide with brk(2), and thus the storage malloc returns will be zeroed 
50in many cases as well, so programmers are not particular apt to notice 
51that their code depends on malloc'ed storage being zeroed.
52.PP
53With problems this big and error handling this weak, it is not
54surprising that problems are hard and time consuming to find and fix.