[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