Memory management and allocation

[Dan Nilsen]

Hi!

I'm writing a small piece of software that basically runs on an
embedded system with a Power-PC cpu. This runs on a stripped down
version of Linux - Busybox.

As I'm writing a piece of code that basically acts as a server and
that will be running for weeks or months and probably even longer,
memory management is a topic that is quite crucial.

Not being a very experienced C programmer, and with next to no help in
the company I currently work in I turn to this forum.

In my program(s), I do have several functions and files as one would
expect.
One of my questions is then: Is it strictly necessary to allocate
memory as in:
BYTE *frame = (BYTE*)malloc(s izeof(BYTE * FRAMELEN); and later to free
this and set the pointer to NULL ? Or can I just allocate the variable
by
BYTE frame[FRAMELEN]; and assume the memory is freed on a function
return?

I'm pretty sure dynamic memory allocation is quite critical in my main
program(the server), in order to avoid any memory leakages.

And as a final question:
If i have code like this:
BYTE *frame = (BYTE*)malloc(s izeof(BYTE * FRAMELEN);
...assign some values to frame...

and then call
free(frame);
frame = NULL;

why do I sometimes get a segmentation fault?

Hope someone has got some good answers for me.

Thanks

Dan Nilsen

[Alex Fraser]

"Dan Nilsen" <da********@gma il.com> wrote in message
news:50******** *************** ***@posting.goo gle.com...

I'm writing a small piece of software that basically runs on an
embedded system with a Power-PC cpu. This runs on a stripped down
version of Linux - Busybox.

As I'm writing a piece of code that basically acts as a server and
that will be running for weeks or months and probably even longer,
memory management is a topic that is quite crucial.

Not being a very experienced C programmer, and with next to no help in
the company I currently work in I turn to this forum.

In my program(s), I do have several functions and files as one would
expect.
One of my questions is then: Is it strictly necessary to allocate
memory as in:
BYTE *frame = (BYTE*)malloc(s izeof(BYTE * FRAMELEN); and later to free
this and set the pointer to NULL ? Or can I just allocate the variable
by
BYTE frame[FRAMELEN]; and assume the memory is freed on a function
return?
Personally, I avoid malloc()/free() where practical in general. It is
typically practical if either the allocation size is small and constant, and
the memory is required only for the lifetime of a function, or the
allocation size is constant and required for the lifetime of the program.
The former seems to apply in your case.

Using malloc()/free() is usually slower and can result in heap
fragmentation, both of which can be quite important in embedded systems.

If using malloc()/free() in C, it is not necessary to cast the return value
of malloc() (and for reasons that are mentioned here from time to time, I
recommend not casting). Nor is it usually necessary to set the pointer to
NULL after calling free(); where it's not necessary, this is typically done
to guard against further (erroneous) use of the freed memory.
I'm pretty sure dynamic memory allocation is quite critical in my main
program(the server), in order to avoid any memory leakages.

And as a final question:
If i have code like this:
BYTE *frame = (BYTE*)malloc(s izeof(BYTE * FRAMELEN);
..assign some values to frame...

and then call
free(frame);
frame = NULL;

why do I sometimes get a segmentation fault?

Common causes of problems when using malloc() and free() are:
- forgetting to #include <stdlib.h>,
- not checking the return value of malloc(), which may be NULL to indicate
failure (problem occurs when you try to dereference the pointer),
- writing outside allocated memory, often somewhere else in the program
(problem most often occurs when calling free(), but can occur at other
times),
- calling free() twice with the same pointer value (problem occurs on the
second call), and
- passing free() a pointer value other than one returned by malloc(),
calloc() or realloc() (including a corrupted pointer value).

Alex

[Christian Kandeler]

Dan Nilsen wrote:

I'm writing a small piece of software that basically runs on an
embedded system with a Power-PC cpu. This runs on a stripped down
version of Linux - Busybox.
I'll assume it's still a hosted implementation.
In my program(s), I do have several functions and files as one would
expect.
One of my questions is then: Is it strictly necessary to allocate
memory as in:
BYTE *frame = (BYTE*)malloc(s izeof(BYTE * FRAMELEN);
and later to free
this and set the pointer to NULL ? Or can I just allocate the variable
by
BYTE frame[FRAMELEN]; and assume the memory is freed on a function
return?
1. You don't have to set the pointer to NULL.
2. If you need the memory only inside of the function and you know the size
in advance, there is really no need for dynamic allocation (unless FRAMELEN
is a really big value). Just define an array, which indeed does not require
a call to free().
And as a final question:
If i have code like this:
BYTE *frame = (BYTE*)malloc(s izeof(BYTE * FRAMELEN);
You don't need the cast, by the way. The type of malloc()'s return value is
pointer to void, which is compatible to any other pointer type.
..assign some values to frame...

and then call
free(frame);
frame = NULL;

why do I sometimes get a segmentation fault?

The way you write it here, there shouldn't be a problem. Perhaps you call
free() several times on the same memory?
Christian

[Michael Mair]

Dan Nilsen wrote:

Hi!

I'm writing a small piece of software that basically runs on an
embedded system with a Power-PC cpu. This runs on a stripped down
version of Linux - Busybox.

As I'm writing a piece of code that basically acts as a server and
that will be running for weeks or months and probably even longer,
memory management is a topic that is quite crucial.

Not being a very experienced C programmer, and with next to no help in
the company I currently work in I turn to this forum.

In my program(s), I do have several functions and files as one would
expect.
One of my questions is then: Is it strictly necessary to allocate
memory as in:
BYTE *frame = (BYTE*)malloc(s izeof(BYTE * FRAMELEN); and later to free
Better use
BYTE *frame = malloc(sizeof *frame * FRAMELEN);
if you dynamically allocate memory. The cast of malloc()'s return
value is unnecessary in C and can hide errors; using sizeof *frame
helps avoid errors if you ever change the type frame points to
(and forget to adjust the sizeof(type) part).
this and set the pointer to NULL ? Or can I just allocate the variable
by
BYTE frame[FRAMELEN]; and assume the memory is freed on a function
return?
It depends.
If you want to use "frame" only within one function (or pass it
to other functions from that function) and do not need it after
reaching the end of the function any more (like in the form of
pointers stored somewhere else which will be used to access the
memory later on), start out with the array version.
<OT>
It is possible that you run into your limits with many large
automatic array objects. ulimit or whatever your system offers
may help you determine and if necessary adjust these limits
beforehand (automatic variables usually come from the stack,
dynamically allocated storage usually from the heap).
</OT>
I'm pretty sure dynamic memory allocation is quite critical in my main
program(the server), in order to avoid any memory leakages.

And as a final question:
If i have code like this:
BYTE *frame = (BYTE*)malloc(s izeof(BYTE * FRAMELEN);
..assign some values to frame...

and then call
free(frame);
frame = NULL;

why do I sometimes get a segmentation fault?
1) The final NULLing is not necessary but may help you keep track
of invalid pointers.
2) _always_ segfaults at free() can mean many things:
- you passed a pointer to storage already free()d
- the free() call _before_ the current one got passed an invalid
argument and internals of the memory management got f...ed up
- Something else happened

Errors I helped find usually fell to equal parts in these
categories but this depends on your programming style and your
implementation.
3) _sometimes_ segfaults are uglier business.

If nothing else helps: Throw out all the code
between malloc() and free(), (replace the necessary stuff by
dummy code,) put it back in little quantities (line by line,
block by block, ...) and see when it crashes.
If you can, use a debugger and tools like valgrind.

It is probably to late for that:

Clear definition of interfaces beforehand, tests for these
interfaces written best ahead of the actual functions,
paranoid assertions in the functions as you go (within some
#ifdef PARANOIA -- #endif preprocessing directives).
Hope someone has got some good answers for me.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Jonathan Burd]

Christian Kandeler wrote:

Dan Nilsen wrote:


<snip>


The way you write it here, there shouldn't be a problem. Perhaps you call
free() several times on the same memory?
Christian

I think he (or something) has changed ``frame" to point to some other
location. If that's true, he would have to restore it to point to the
original location. Otherwise, I don't see a problem with free(frame).

Regards,
Jonathan.

--
Email: "jonathan [period] burd [commercial-at] gmail [period] com" sans-WSP

"We must do something. This is something. Therefore, we must do this."
- Keith Thompson

[Giovanni]

On 02/03/05 07:40, Dan Nilsen wrote:

I'm pretty sure dynamic memory allocation is quite critical in my main
program(the server), in order to avoid any memory leakages.

I found very useful to run a lint program that warns you of mishandled
malloc/free. You still have to check all warnings but detects a lot of
possible leakages.

Ciao
Giovanni
--
A computer is like an air conditioner,
it stops working when you open Windows.
Registered Linux user #337974 <http://counter.li.org/>

[Dan Nilsen]

Thanks guys!

All help and answers came in handy, and I have sorted out most of my
problems regarding this project. I've basically taken over this
project from someone else, and there is next to no design documents
nor comments in the code I "inherited" . This didn't make it any easier
for me - I do however have a better understanding of pointers and
memory in C, and the common pitfalls associated with the use of them.

Dan Nilsen

[Joakim Hove]

Hello,

just one random thougth - which it seems no one else has touched
upon. I like this style:
If the function in question is called many times (from the same scope)
, it might be a viable option to allocate the frame buffer in the
calling scope:

void function(...., BYTE *frame) {
/* Work with frame */
}

calling scope:

BYTE *frame = malloc()
/*
Code with several calls like this:
*/
function(..., frame);
/*
Finally - no more calls to function().
*/
free(frame);
Of course, this only has merit if the function using frame is called
*many times*.
Anyway - good luck;
HTH - Joakim

--
Joakim Hove
hove AT ift uib no
Tlf: [phone]
Fax: [phone]
http://www.ift.uib.no/~hove/