In article <firstname.lastname@example.org>, David Gibbs <email@example.com> wrote:
Alain Bonnefoy <> firstname.lastname@example.org> > wrote:
I have problem while freeing an allocated memory area.
After I free a pathname’s attribute structure, subsequent malloc() call
runs into an infinite loop with the CPU at 100 %
I have no precise infos about my problems but my question is here.
I don’t really know how the malloc_g library could help me. I tried it but
I cannot really see how and what usefull informations to get.
Can you give some ideas?
This usually means you’ve corrupted the malloc/free-list somewhere.
Sounds like it sure enough.
If you haven’t done so, read the tech note on heap corruption.
– have you freed an area of memory that wasn’t allocated?
– have you freed an area of memory that was already freed?
Same thing, effectively. If you had linked against malloc_g, it would
have written a warning to stderr that this had occurred.
– have you called free on a pointer that is part way through
an allocated piece of memory?
– have you written before the start or past the end of an allocated
piece of memory?
– Or writing to unallocated memory through a stale pointer (a block that
Boundary errors are a nasty thing. Finding them effectively might require
more work. If you suspected over/underflow and were reasonably certain
it happened following the call to free(), and could easily isolate the
call – is it the first such call to free, or the n-th? – you could use
mallopt to enable additional check (MALLOC_FILLAREA and MALLOC_CKCHAIN, both
described in the tech note).
Thinking about these problems, I really don’t understand why free() doesn’t
return the amount of bytes given back to the system! It could very cool to
find a problem with this information!
Might be neat – but we can’t implement it that way, free is an ANSI
And not very practical in any case. You would likely never see what you
were expecting. Most allocators don’t usually give you the exact size
of block you requested, so the amount returned to the heap would differ
from the requested size anyway. The free operation might also coalesce
blocks. Should it tell you the size of the newly coalesced block or
the original size? In the case of an invalid pointer, the information
would be completely unpredictable because the allocator wouldn’t find
the correct block header. In the worst case, it would find something
that looked legitimate and the return value from free would give you a false
sense of security.
Steve Furr email: email@example.com
QNX Software Systems, Ltd.