[so] Curiozitate valgrind / exec

[Dragos Tarcatu]

Salut,

Am dat peste o situatie relativ ciudata legata de alocarea dinamica/folosirea 
functiilor exec/utilizarea valgrind. Constituie  exemplul urmator o situatie de 
memory leak?

#include <unistd.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    int* x = (int* )malloc(100 * sizeof(int));
    char * command[] = {"ls", NULL};
    execvp("ls", command);
    return 0;
}

Intreb asta pentru ca la rularea sub valgrind sunt raportate urmatoarele:
dragosh at elitebook:~/workspace/test$ valgrind --trace-children=yes ./test

...
=6009== LEAK SUMMARY:
==6009==    definitely lost: 120 bytes in 1 blocks
==6009==    indirectly lost: 0 bytes in 0 blocks
==6009==      possibly lost: 0 bytes in 0 blocks
==6009==    still reachable: 19,311 bytes in 11 blocks
==6009==         suppressed: 0 bytes in 0 blocks
...

Am modificat programul la ceva de forma:

#include <unistd.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    int* x = (int* )malloc(100 * sizeof(int));
    char * command[] = {"ls", NULL};
    int status;

    pid_t pid = fork();
    if (pid > 0) {
        //free(x);
        wait(&status);
    }
    else if (pid == 0)
    {
        execvp("ls", command);
    }
    return 0;
}

In acest caz raportul valgrind arata ceva de genul:
dragosh at elitebook:~/workspace/test$ valgrind --trace-children=yes ./test
... (procesul parinte)
==6112== LEAK SUMMARY:
==6112==    definitely lost: 400 bytes in 1 blocks
==6112==    indirectly lost: 0 bytes in 0 blocks
==6112==      possibly lost: 0 bytes in 0 blocks
==6112==    still reachable: 0 bytes in 0 blocks
==6112==         suppressed: 0 bytes in 0 blocks
...
...(procesul copil)
==6115== LEAK SUMMARY:
==6115==    definitely lost: 120 bytes in 1 blocks
==6115==    indirectly lost: 0 bytes in 0 blocks
==6115==      possibly lost: 0 bytes in 0 blocks
==6115==    still reachable: 19,311 bytes in 11 blocks
==6115==         suppressed: 0 bytes in 0 blocks
...

Ar putea cineva sa-mi explice de ce este raportat memory leak (si mai ales de 
unde acea dimensiune! ...) in acest caz?

Multumesc,

    Dragos



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/lurker/list/so.html/attachments/20100924/872ebe68/attachment.html>