Memory
related problems are common in software development for embedded system. During
module testing, unit testing it is always essential to make sure that there is
no memory related error. There are open source free tools available. Val grind
is one of them. There are paid tools too.
Most of the memory related problems are associated with dynamic memory allocation. Following are list of some of the common memory related problems.
1. Memory Leak. This is the case when memory is not freed once its usage is finished.
2. Invalid Write. This is the case writing to memory location without proper memory allocation. May be writing to memory location after freed up.
3. Invalid Read. This is the case reading memory location without proper memory initialization. May be reading memory after it freed up.
In context of embedded system/real time system following are the challenges of finding out memory related problems.
1. Real time system has constraints of time so enabling memory leak testing may be difficult which has extra processing overhead.
2. In embedded system most of the time pool of memory is allocated during boot up and dynamically allocated from the pool rather from heap. This is required to achieve predictability behaviour which is very much essential in embedded application. When we use memory pool library instead of standard library of memory allocation, memory debugging tool like valgrind can’t find any of the memory related error mentioned before.
Following section gives some of the technique to address above mentioned challenges.
First challenge can be addressed by having host based testing environment. It is worth to spend time to build adapters required to simulate target behaviour (need not be 100%) and perform memory leak testing on host PC using memory debugging tool such as valgrind. We can compromise on real time constraints and can execute functionality on host and find memory related error if not every error but most of the error.
Second challenge can be addressed by having macros for memory allocation/de-allocation API and by having condition compilation to enable system call rather memory pool allocation Api, whenever memory debugging is required.
void* alloc_mem (struct mem_pool* pool, int size)
{
void* mem = NULL;
#ifdef MEMORY_TEST_ENABLED
mem = malloc (size);
#else
mem = alloc_from_pool (pool, size);
#endif
return (mem);
}
Most of the memory related problems are associated with dynamic memory allocation. Following are list of some of the common memory related problems.
1. Memory Leak. This is the case when memory is not freed once its usage is finished.
2. Invalid Write. This is the case writing to memory location without proper memory allocation. May be writing to memory location after freed up.
3. Invalid Read. This is the case reading memory location without proper memory initialization. May be reading memory after it freed up.
In context of embedded system/real time system following are the challenges of finding out memory related problems.
1. Real time system has constraints of time so enabling memory leak testing may be difficult which has extra processing overhead.
2. In embedded system most of the time pool of memory is allocated during boot up and dynamically allocated from the pool rather from heap. This is required to achieve predictability behaviour which is very much essential in embedded application. When we use memory pool library instead of standard library of memory allocation, memory debugging tool like valgrind can’t find any of the memory related error mentioned before.
Following section gives some of the technique to address above mentioned challenges.
First challenge can be addressed by having host based testing environment. It is worth to spend time to build adapters required to simulate target behaviour (need not be 100%) and perform memory leak testing on host PC using memory debugging tool such as valgrind. We can compromise on real time constraints and can execute functionality on host and find memory related error if not every error but most of the error.
Second challenge can be addressed by having macros for memory allocation/de-allocation API and by having condition compilation to enable system call rather memory pool allocation Api, whenever memory debugging is required.
void* alloc_mem (struct mem_pool* pool, int size)
{
void* mem = NULL;
#ifdef MEMORY_TEST_ENABLED
mem = malloc (size);
#else
mem = alloc_from_pool (pool, size);
#endif
return (mem);
}
No comments:
Post a Comment