Modern Linux memory management

[Baruch Siach]

Hi Ido,

On Thu, Jan 26, 2012 at 04:34:28PM +0200, ik wrote:
> In the past week I had several bugs that while gdb pointed to a place X,
> the actual place was several instructions prior to that position.
> 
> For example the following error message I had to an off by one bug:
> *** glibc detected *** ./test_parser: malloc(): memory corruption (fast):
> 0x0000000001ddad50 ***
> 
> The instruction set that I was at, when glibc raised this exception was a
> lot further then the original position of the function that caused it have
> been executed.
> Only by using valgrind, that I could find the exact location and figure
> out, that it was another function that had the problem.
> 
> How does the modern memory management system is working then, that it takes
> so much time for the problem to surface ?

This problem has nothing to do with Linux (in the sense of the kernel used).

The malloc() routine is implemented in glibc. For its malloc() implementation 
glibc uses its own set of data structures to keep track of free memory chunks 
and the size of allocated chunks. Note that the free() routing accepts just 
one parameter, the pointer to free. glibc must then figure out what was the 
size of the memory chunk that this pointer points to.

Now, if you corrupt the internal glibc data structure, glibc won't notice 
until you try to call one of malloc(), free(), etc.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -