> Hello Everybody,
>
>
> the problem is...
> i have a process. it dynamically allocates memory and the
> allocated memory is not freed...
C is a language which assumes that the programmer
knows what he (she, in this case!) is doing.
C does not provide garbage collection. In fact,
the C Standard explicitly mentions that each malloc
/calloc/realloc should have a corresponding free(3).
Anyway, read on ...
> now an API is needed which
> sees that dynamic allocated memory and frees without the programer
> need to write the free...the fact is the process will be running still
> and the memory should be checked and freed...no usage of mempatrol or
> any such...
> the code shoud be in c...
After reading your mail, I thought of writing some code.
But, unfortunately couldn't, and thought just to give an
idea and leave implementation to you. I have an idea as
how we can do this. At the end, I also point out what are
the problems that we encounter. (I hasten out to say that
I may not be correct.)
1. Divide the sources into two files:
app.c - Main application program
lock.c - Memory locking and freeing functions.
This would be compiled as:
$ gcc app.c lock.c -Wall -ansi
2. First, let me bring out what is in my mind about lock.c:
typedef
struct _lock
{
/*
* memory addr to be freed later.
*/
const char * mem;
/*
* Whether the memory pointer by MEM is locked or
* not?
*/
unsigned locked :1;
/*
* Padding
*/
unsigned :0;
} lock_t, *plock_t;
static lock_t lock_arr[LOCK_MAX] = { { 0, 0 }, };
We also will be having following functions:
void lock_mem ( const char * mem );
Description:
Whenever the app.c calls either of allocation
function, it will call this function with the return
value of malloc or calloc. For example,
mem = malloc ( 10 );
if ( mem )
lock_mem ( mem );
...
void unlock_mem ( const char * mem );
Description:
Exact opposite of lock_mem () function. App.c
will call this whenever it does not require the memory.
void timer ( int sig );
Description:
This is the SIGALRM signal handler, goes through
the LOCK_MEM array and frees which ever is unlocked.
It will set the timer again by calling alarm(2) with
appropriate delay.
3. App.c will be your normal program with following exceptions:
+ Whenever you allocated, you call lock_mem ()
+ Whenever you want to free, you call unlock_mem ()!
Think of this: You cut a roti and apply some sabji with
your right hand; then give the roti to your left hand;
left hand will take a round via your neck and give it
back to the right hand; right hand ultimately will give
to the mouth!
Atleast, this is what I have done here.
> if i use gcc __attrib__((destructor)
> i can clean after thr process is exited. but i nedd the process kept
> running and free the unused memory..plzz give some solution for this.
>
> ---sunita
4. This relates to app.c:
Instead, I use __attribute__ ((constructor)).
void
initialize ( void ) __attribute__ (( constructor ));
void
initialize ( void )
{
...
signal ( SIGALRM, timer );
alarm ( 2 ); /* garbage collection every 2 seconds */
...
}
PROBLEMS:
1. Heavily Linux/Unix specific. Because the SIGALRM is not
found in DOS environment. The Standard defines only
following signals:
SIGABRT SIGFPE SIGILL
SIGINT SIGSEGV SIGTERM
See man pages for descriptions.
2. We are simply increasing the program complexity by writing
lock.c just to call free.
3. If you have a global memory pointer, when and where the
program will use, we can not say. If we free this
memory, memory corruption might happen.
(Memory corruption : Freeing memory which in use
Memory leak : Not freeing memory which is
not in use)