Even though malloc(3) is a lot simpler to use than the raw brk(2)/sbrk(2) interface, or maybe exactly because of that, a lot of problems arise from its use.
The handling of these problems have traditionally been weak. A core-dump was the most common form for "handling", but in rare cases one could experience the famous "malloc: corrupt arena." message before the core-dump. Even worse though, very often the program will just continue, possibly giving wrong results.
An entirely different form of problem is that the memory returned by malloc(3) can contain any value. Unfortunately most kernels, correctly, zero out the storage they provide with brk(2), and thus the storage malloc returns will be zeroed in many cases as well, so programmers are not particular apt to notice that their code depends on malloc'ed storage being zeroed.
With problems this big and error handling this weak, it is not surprising that problems are hard and time consuming to find and fix.