[uClibc]Re: malloc, munmap, etc...

Miles Bader miles at lsi.nec.co.jp
Mon Nov 11 04:52:06 UTC 2002


Uwe Beutin <uwe at imbrium.de> writes:
> > Also, what does `it's probably a boa-thing with its implementatin of
> > free' mean?  Does boa implement it's own version of the `free'
> > function (what about malloc)?
> 
> No, I had thought that boa mmap's memory and if I understood correctly, 
> the munmap messages appear when an application tries to free() any of 
> it's allocated memory more than once?!

The munmap messages appear when the a process tries to munmap a memory
region that's not exactly the same as an earlier mmap request.  However
munmap calls only loosely match calls to free (if a free increases the
amount of contiguous memory in the malloc heap beyond a certain point,
free will try to use munmap to return the memory to the kernel).

> Anyway, after the implementation of __UCLIBC_UCLINUC_BROKEN_MUNMAP__ and 
> re-linking with the current libc/strlib/malloc tree, the munmap messages 
> with boa are still there. Funny, why only boa?! And only when the a 
> web page is being requested, and then, not every time?!

The first thing I would do is just make sure that boa is _really_
using the fixed malloc (I've many times gone nuts trying to debug
something only to realize that what I thought had been recompiled
actually hadn't been).

There should be a boa.elf file where you compiled boa
(.../user/boa/src/boa.elf?), which you can check for the symbol
`__malloc_mmapped_blocks', e.g.:

   nm user/boa/src/boa.elf | grep __malloc_mmapped_blocks

Then, if that shows positive output, check to make sure that the
installed flat-executable matches, e.g.:

   ls -l user/boa/src/boa romfs/bin/boa

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]



More information about the uClibc mailing list