Finding memory allocation problems

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

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?

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!

Thanks,
Alain.

2

Alain Bonnefoy <bonnefoy@club-internet.fr> 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.

– have you freed an area of memory that wasn’t allocated?
– have you freed an area of memory that was already freed?
– 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?

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
function.

-David

QNX Training Services
dagibbs@qnx.com

3

In article <9f8omn$6m2$1@nntp.qnx.com>, David Gibbs <dagibbs@qnx.com> wrote:

Alain Bonnefoy <> bonnefoy@club-internet.fr> > 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?

As above.

– 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
was freed).

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
function.

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: furr@qnx.com
QNX Software Systems, Ltd.

4

Steve Furr a écrit :

In article <9f8omn$6m2$> 1@nntp.qnx.com> >, David Gibbs <> dagibbs@qnx.com> > wrote:
Alain Bonnefoy <> bonnefoy@club-internet.fr> > 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?

As above.

– 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
was freed).

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
function.


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: > furr@qnx.com
QNX Software Systems, Ltd.

Ok, for everything Steve and David. I found mt problem - 2 call of free() for the
same pointer !

One precision anyway.

After a call to free() the pointer is still equal to its previous address, instead
of NULL, I suppose that it’s ANSI but do you know the reason of this choice,
because a call to free() with a NULL parameter is safe - not clean but safe ?
Would there exist more problems if the pointer was setted to NULL by free() ?

Thanks,
Alain.

5

Alain Bonnefoy wrote:

Ok, for everything Steve and David. I found mt problem - 2 call of free() for the
same pointer !

One precision anyway.

After a call to free() the pointer is still equal to its previous address, instead
of NULL, I suppose that it’s ANSI but do you know the reason of this choice,
because a call to free() with a NULL parameter is safe - not clean but safe ?
Would there exist more problems if the pointer was setted to NULL by free() ?

Thanks,
Alain.

I don’t know what ANSI/POSIX requires. Nothing prevents you from setting your pointer
to NULL after free returns, thus hiding extra calls to free, if you wish to hide
them. Or you could check if your pointer is NULL before calling free, if you don’t
wish to hide extra ones.

6

Dean Douthat a écrit :

Alain Bonnefoy wrote:

Ok, for everything Steve and David. I found mt problem - 2 call of free() for the
same pointer !

One precision anyway.

After a call to free() the pointer is still equal to its previous address, instead
of NULL, I suppose that it’s ANSI but do you know the reason of this choice,
because a call to free() with a NULL parameter is safe - not clean but safe ?
Would there exist more problems if the pointer was setted to NULL by free() ?

Thanks,
Alain.

I don’t know what ANSI/POSIX requires. Nothing prevents you from setting your pointer
to NULL after free returns, thus hiding extra calls to free, if you wish to hide
them. Or you could check if your pointer is NULL before calling free, if you don’t
wish to hide extra ones.

Of course! but as I think that ANSI/POSIX peoples think about what they decide, I was
supposing that there is a good reason to do like that!

thanks,
Alain.

7

Alain Bonnefoy wrote:

Dean Douthat a écrit :

Alain Bonnefoy wrote:

Ok, for everything Steve and David. I found mt problem - 2 call of free() for the
same pointer !

One precision anyway.

After a call to free() the pointer is still equal to its previous address, instead
of NULL, I suppose that it’s ANSI but do you know the reason of this choice,
because a call to free() with a NULL parameter is safe - not clean but safe ?
Would there exist more problems if the pointer was setted to NULL by free() ?

Thanks,
Alain.

I don’t know what ANSI/POSIX requires. Nothing prevents you from setting your pointer
to NULL after free returns, thus hiding extra calls to free, if you wish to hide
them. Or you could check if your pointer is NULL before calling free, if you don’t
wish to hide extra ones.

Of course! but as I think that ANSI/POSIX peoples think about what they decide, I was
supposing that there is a good reason to do like that!

thanks,
Alain.

I believe the reason is they don’t wish to silently hide possible problems, leaving it to
users to handle instead.

8

Previously, Dean Douthat wrote in qdn.public.qnxrtp.os:

Alain Bonnefoy wrote:

Dean Douthat a écrit :

Alain Bonnefoy wrote:

Ok, for everything Steve and David. I found mt problem - 2 call of free() for the
same pointer !

One precision anyway.

After a call to free() the pointer is still equal to its previous address, instead
of NULL, I suppose that it’s ANSI but do you know the reason of this choice,
because a call to free() with a NULL parameter is safe - not clean but safe ?
Would there exist more problems if the pointer was setted to NULL by free() ?

Thanks,
Alain.

I don’t know what ANSI/POSIX requires. Nothing prevents you from setting your pointer
to NULL after free returns, thus hiding extra calls to free, if you wish to hide
them. Or you could check if your pointer is NULL before calling free, if you don’t
wish to hide extra ones.

Of course! but as I think that ANSI/POSIX peoples think about what they decide, I was
supposing that there is a good reason to do like that!

thanks,
Alain.

I believe the reason is they don’t wish to silently hide possible problems, leaving it to
users to handle instead.

Also if you look at free() you see that the pointer is passed by value - thus there is no way that your copy can be set to NUL by the free function.

void free( void* ptr );

–
David L. Hawley D.L. Hawley and Associates

9

David Hawley a écrit :

Previously, Dean Douthat wrote in qdn.public.qnxrtp.os:


Alain Bonnefoy wrote:

Dean Douthat a écrit :

Alain Bonnefoy wrote:

Ok, for everything Steve and David. I found mt problem - 2 call of free() for the
same pointer !

One precision anyway.

After a call to free() the pointer is still equal to its previous address, instead
of NULL, I suppose that it’s ANSI but do you know the reason of this choice,
because a call to free() with a NULL parameter is safe - not clean but safe ?
Would there exist more problems if the pointer was setted to NULL by free() ?

Thanks,
Alain.

I don’t know what ANSI/POSIX requires. Nothing prevents you from setting your pointer
to NULL after free returns, thus hiding extra calls to free, if you wish to hide
them. Or you could check if your pointer is NULL before calling free, if you don’t
wish to hide extra ones.

Of course! but as I think that ANSI/POSIX peoples think about what they decide, I was
supposing that there is a good reason to do like that!

thanks,
Alain.

I believe the reason is they don’t wish to silently hide possible problems, leaving it to
users to handle instead.

Also if you look at free() you see that the pointer is passed by value - thus there is no way that your copy can be set to NUL by the free function.

void free( void* ptr );

–
David L. Hawley D.L. Hawley and Associates

Correct,
Thanks,
Alain

10

In article <3B1E1637.80E97069@icbt.com>,
Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

David Hawley a écrit :

Also if you look at free() you see that the pointer is passed by value -
thus there is no way that your copy can be set to NUL by the free function.

void free( void* ptr );

One trick I’ve seen (and used) in a few places is to define a different
freeing function which helps with this

void*
freePtr(void* ptr)
{
free(ptr);
return NULL;
}

Your code then reads:

myPtr = freePtr(myPtr);

Of course, this is all just syntactic sugar. Your mileage may vary.

Regards,
Eric

11

Alain Bonnefoy <alain.bonnefoy@icbt.com> wrote:

Steve Furr a ecrit :

Ok, for everything Steve and David. I found mt problem - 2 call of free() for the
same pointer !

One precision anyway.

After a call to free() the pointer is still equal to its previous address, instead
of NULL, I suppose that it’s ANSI but do you know the reason of this choice,
because a call to free() with a NULL parameter is safe - not clean but safe ?
Would there exist more problems if the pointer was setted to NULL by free() ?

Among other things, it would require a re-definition of the interface to
free() – free() would have to take the address of the pointer in order
to update it, rather than just the pointer. And, this would only help for
the easy cases to catch – when the exact same variable is used in both
the good and bad free() calls – very often a different pointer to the
same memory area is used.

-David

QNX Training Services
dagibbs@qnx.com

12

David Gibbs a écrit :

Alain Bonnefoy <> alain.bonnefoy@icbt.com> > wrote:
Steve Furr a ecrit :

Ok, for everything Steve and David. I found mt problem - 2 call of free() for the
same pointer !

One precision anyway.

After a call to free() the pointer is still equal to its previous address, instead
of NULL, I suppose that it’s ANSI but do you know the reason of this choice,
because a call to free() with a NULL parameter is safe - not clean but safe ?
Would there exist more problems if the pointer was setted to NULL by free() ?

Among other things, it would require a re-definition of the interface to
free() – free() would have to take the address of the pointer in order
to update it, rather than just the pointer. And, this would only help for
the easy cases to catch – when the exact same variable is used in both
the good and bad free() calls – very often a different pointer to the
same memory area is used.

-David

QNX Training Services
dagibbs@qnx.com

That’s right, these problems are definitively difficult to control and the best to do is
certainly a good thinking.
This is the weak spot of the ‘C’ language and it’s power also.

Thanks,
Alain.