iLiad How to collect system resource?

[ericshliao]

I am working on a cbz/cbr viewer. I used popen function to call unzip/unrar and get their output. Basically, this medthod works, but it seems to occupy more and more system resource even after unzip/unrar finished their jobs. This problem caused app crash.
I tried pipe/fork, still same problem.

I wonder if there are ways to re-collect system resource.

If not possible, then the only way left to me is finding a proper wrapped zip/rar lib and call it in my app.

[Antartica]

Originally Posted by ericshliao

I am working on a cbz/cbr viewer. I used popen function to call unzip/unrar and get their output. Basically, this medthod works, but it seems to occupy more and more system resource even after unzip/unrar finished their jobs. This problem caused app crash.
I tried pipe/fork, still same problem.

I wonder if there are ways to re-collect system resource.

If not possible, then the only way left to me is finding a proper wrapped zip/rar lib and call it in my app.

I suppose that you're exhausting the available memory.

POPEN

The popen() doesn't need anything apart of the close() call to the file descriptor (the OS should recollect the child afterwards).

FORK

If you use fork, the you have to recollect (use the waitpid() function) the finished children or the OS will leave them using memory until you recollect them, just for the sake of being notified of the exit value of the child program.

For a code example on how to do it, look at xepdmgr, as it manages the spawning/recollection of the launched app.

What you have to do:
1. Install a signal handler for sigint, so that you are informed when a child has exited. Remember that in signal handlers not all library functions are allowed; to be in the safe side, limit yourself to only use read()/write() to a pipe so that your main loop can detect it; alternatively you can set a flag variable and cross your fingers that your main loop sees it soon.
2. When a child has exited, you have to call waitpid() ro recollect the status of the exited application. Once you recollect it, the OS will free the resources used by that child program.

[ericshliao]

Yes, the system resource that I mentioned above is available memory.

In popen, I call pclose (not close). If pclose and close can do the same work, then I should have re-collected unused momroy. Exausted available memory should not happen in this scenario. Quite strange.

In fork scenario, I call execlp to execute unzip/unrar in child process. I supposed that after executed execlp, the child process is ended. Can't OS re-collect the memory occupied by child process?
According to your words, I have to call waitpid() to free occupied memory. I will try it. Thanx.

Added:
I checked your xepdmgr.c. I think the relevant section are:

static
int ReapChildren(int Pid)
{
        int reaped_pid,status;
        while(1) {
                reaped_pid=waitpid(-1,&status,WNOHANG|WUNTRACED);
                if(reaped_pid<=0)
                        break;
                if(reaped_pid==Pid)
                        return(0);
        }
        return(-1);
}

[ericshliao]

I modified my code to call waitpid, but the problem still existed. Then, I tried another option: calling proper wrapped zlib (zzip lib), the result is the same.
Now, I have another guess: the problem might come from the GtkWidget and GdkPixbuf that I used to load and store image. It might because the old one is not cleared when I create a new one, even though I always re-use the same pointers to point to GtkWidget and GdkPixbuf.
Oh! I love Java. When I set a pointer or object to null, JVM will collect garbage automatically for me.

[Antartica]

Originally Posted by ericshliao

Now, I have another guess: the problem might come from the GtkWidget and GdkPixbuf that I used to load and store image. It might because the old one is not cleared when I create a new one, even though I always re-use the same pointers to point to GtkWidget and GdkPixbuf.
Oh! I love Java. When I set a pointer or object to null, JVM will collect garbage automatically for me.

To debug this type of errors, valgrind (http://valgrind.org/ ; "apt-get install valgrind") is of great help.

valgrind --leak-check=full --show-reachable=yes ./myprog 2>/tmp/valgrind.log

You will get at program exit the locations of the mallocs of the memory that was leaked. You have to compile your program with debugging information (i.e. "gcc -g myprog.c -o myprog")

The only catch is that you have to use a build of your program for x86 (not for arm/scratchbox), but I suppose that you already have the makefiles prepared for that to ease debugging :-)

[ericshliao]

I almost can be sure that available memory is consumed by repeatedly using GdkPixbuf and GdkPixbufLoader to load image. Because when I insert some line with g_object_unref, my app seemed to consume available memory in a slower rate. It survived a little longer and then crashed.

I will try falgrind. Thanx.