Ca o continuare a curiozitatii tale: care este outputul in ambele cazuri
daca imediat dupa malloc faci si x[99] = 123; ? :)
Valentin
2010/9/24 Dragos Tarcatu <tarcatu_dragosh at yahoo.com>
> 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
>
>
> _______________________________________________
> http://elf.cs.pub.ro/so/wiki/resurse/lista-discutii
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cursuri.cs.pub.ro/lurker/list/so.html/attachments/20100924/ca421049/attachment.htm>