|
From: Wan M. F. W. I. <wan...@mc...> - 2011-04-21 15:17:43
|
Hi,
I want to share my findings which I don't really understand and hope
some explanations from you guys. I compiled a simple program as below:
#include <stdio.h>
#include <stdlib.h>
int main()
{
char *p;
// Allocation #1 of 19 bytes
p = (char *) malloc(19);
// Allocation #2 of 12 bytes
p = (char *) malloc(12);
free(p);
// Allocation #3 of 16 bytes
p = (char *) malloc(16);
return 0;
}
I've compiled using the commands below:
gcc -o test-x86 -g simple.c
gcc -o test-x86-static -g -static simple.c
arm-none-linux-gnueabi-gcc -o test-arm -g simple.c
arm-none-linux-gnueabi-gcc -o test-arm-static -g -static simple.c
I test each program using $ valgrind --tool=memcheck --leak-check=yes
--show-reachable=yes --num-callers=20
P/S : I removed unnecessary lines from the trace below.
** ARM UBUNTU **
ubuntu@ubuntu-desktop:~$ valgrind --tool=memcheck --leak-check=yes
--show-reachable=yes --num-callers=20 ./test-arm
==3246== HEAP SUMMARY:
==3246== in use at exit: 35 bytes in 2 blocks
==3246== total heap usage: 3 allocs, 1 frees, 47 bytes allocated
==3246==
==3246== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2
==3246== at 0x482E3E4: malloc (vg_replace_malloc.c:236)
==3246== by 0x8493: main (simple.c:16)
==3246==
==3246== 19 bytes in 1 blocks are definitely lost in loss record 2 of 2
==3246== at 0x482E3E4: malloc (vg_replace_malloc.c:236)
==3246== by 0x846B: main (simple.c:9)
==3246==
==3246== LEAK SUMMARY:
==3246== definitely lost: 35 bytes in 2 blocks
==3246== indirectly lost: 0 bytes in 0 blocks
==3246== possibly lost: 0 bytes in 0 blocks
==3246== still reachable: 0 bytes in 0 blocks
==3246== suppressed: 0 bytes in 0 blocks
==3246==
==3246== For counts of detected and suppressed errors, rerun with: -v
==3246== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 13 from 6)
ubuntu@ubuntu-desktop:~$ valgrind --tool=memcheck --leak-check=yes
--show-reachable=yes --num-callers=20 ./test-arm-static
==3243== HEAP SUMMARY:
==3243== in use at exit: 0 bytes in 0 blocks
==3243== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==3243==
==3243== All heap blocks were freed -- no leaks are possible
==3243==
==3243== For counts of detected and suppressed errors, rerun with: -v
==3243== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
** ARM ANDROID **
# valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
--num-callers=20 ./test-arm
valgrind: m_ume.c: can't open interpreter
# valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
--num-callers=20 ./test-arm-static
==2131== HEAP SUMMARY:
==2131== in use at exit: 0 bytes in 0 blocks
==2131== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2131==
==2131== All heap blocks were freed -- no leaks are possible
==2131==
==2131== For counts of detected and suppressed errors, rerun with: -v
==2131== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
** X86 UBUNTU **
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
--num-callers=20 ./test-x86
==13235== HEAP SUMMARY:
==13235== in use at exit: 35 bytes in 2 blocks
==13235== total heap usage: 3 allocs, 1 frees, 47 bytes allocated
==13235==
==13235== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2
==13235== at 0x4C284A8: malloc (vg_replace_malloc.c:236)
==13235== by 0x40059D: main (simple.c:16)
==13235==
==13235== 19 bytes in 1 blocks are definitely lost in loss record 2 of 2
==13235== at 0x4C284A8: malloc (vg_replace_malloc.c:236)
==13235== by 0x400575: main (simple.c:9)
==13235==
==13235== LEAK SUMMARY:
==13235== definitely lost: 35 bytes in 2 blocks
==13235== indirectly lost: 0 bytes in 0 blocks
==13235== possibly lost: 0 bytes in 0 blocks
==13235== still reachable: 0 bytes in 0 blocks
==13235== suppressed: 0 bytes in 0 blocks
==13235==
==13235== For counts of detected and suppressed errors, rerun with: -v
==13235== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
--num-callers=20 ./test-x86-static
A lot of output from this one -> http://pastebin.com/efnicUD5
==13238==
==13238==
==13238== HEAP SUMMARY:
==13238== in use at exit: 0 bytes in 0 blocks
==13238== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==13238==
==13238== All heap blocks were freed -- no leaks are possible
==13238==
==13238== For counts of detected and suppressed errors, rerun with: -v
==13238== Use --track-origins=yes to see where uninitialised values come
from
==13238== ERROR SUMMARY: 66 errors from 58 contexts (suppressed: 0 from 0)
What do you guys think? Did I do something wrong? Because out of 6 tests, 3
tests for static executable give wrong results.
Thanks
Regards,
--
Wan Mohd Fairuz WAN ISMAIL
15 Le Palais des Fleurs,
74 Boulevard Raymond Poincare,
06160 Juan les Pins, FRANCE.
http://www.watt.com.my
+6 017 2071591
|
|
From: Dan K. <da...@ke...> - 2011-04-21 16:11:43
|
On Thu, Apr 21, 2011 at 3:17 PM, Wan Mohd Fairuz Wan Ismail
<wan...@mc...> wrote:
> Hi,
> I want to share my findings which I don't really understand and hope
> some explanations from you guys. I compiled a simple program as below:
> #include <stdio.h>
> #include <stdlib.h>
> int main()
> {
> char *p;
> // Allocation #1 of 19 bytes
> p = (char *) malloc(19);
> // Allocation #2 of 12 bytes
> p = (char *) malloc(12);
> free(p);
> // Allocation #3 of 16 bytes
> p = (char *) malloc(16);
> return 0;
> }
> I've compiled using the commands below:
> gcc -o test-x86 -g simple.c
> gcc -o test-x86-static -g -static simple.c
> arm-none-linux-gnueabi-gcc -o test-arm -g simple.c
> arm-none-linux-gnueabi-gcc -o test-arm-static -g -static simple.c
I wonder if the compiler is optimizing away the function calls.
Try using -O1 or -O0 when compiling.
- Dan
|
|
From: Julian S. <js...@ac...> - 2011-04-21 18:54:09
|
> # valgrind --tool=memcheck --leak-check=yes --show-reachable=yes > --num-callers=20 ./test-arm-static > ==2131== HEAP SUMMARY: > ==2131== in use at exit: 0 bytes in 0 blocks > ==2131== total heap usage: 0 allocs, 0 frees, 0 bytes allocated > ==2131== > ==2131== All heap blocks were freed -- no leaks are possible > ==2131== > ==2131== For counts of detected and suppressed errors, rerun with: -v > ==2131== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) This happens because the executable is statically linked, so Memcheck fails to intercept the malloc/free calls, and so it doesn't think that the program didn't do any malloc/free calls. Memcheck won't work properly in this situation. J |
|
From: Wan M. F. W. I. <wan...@mc...> - 2011-04-21 19:44:01
|
Thanks for the clearification about statically link executables. How about
the message valgrind: m_ume.c: can't open interpreter
Since I don't know in detail how valgrind works in the backend, I only come
up that it comes from m_ume.c. Any idea on why it not capable to open the
intepreter (I'm assuming the interpreter is the one that will analyze the
executable?).
case PT_INTERP: {
char *buf = VG_(malloc)(ph->p_filesz+1);
Int j;
Int intfd;
Int baseaddr_set;
vg_assert(buf);
VG_(pread)(fd, buf, ph->p_filesz, ph->p_offset);
buf[ph->p_filesz] = '\0';
sres = VG_(open)(buf, VKI_O_RDONLY, 0);
if (sres.isError) {
VG_(printf)("valgrind: m_ume.c: can't open interpreter\n");
VG_(exit)(1);
}
intfd = sres.res;
Regards,
Fairuz
2011/4/21 Julian Seward <js...@ac...>
>
> > # valgrind --tool=memcheck --leak-check=yes --show-reachable=yes
> > --num-callers=20 ./test-arm-static
> > ==2131== HEAP SUMMARY:
> > ==2131== in use at exit: 0 bytes in 0 blocks
> > ==2131== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> > ==2131==
> > ==2131== All heap blocks were freed -- no leaks are possible
> > ==2131==
> > ==2131== For counts of detected and suppressed errors, rerun with: -v
> > ==2131== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
> This happens because the executable is statically linked, so Memcheck
> fails to intercept the malloc/free calls, and so it doesn't think that
> the program didn't do any malloc/free calls. Memcheck won't work
> properly in this situation.
>
> J
>
--
Wan Mohd Fairuz WAN ISMAIL
OMAP System Multimedia Integration Team (Trainee)
Texas Instrument France
f-w...@ti...
+33 (0)4 93 22 20 16
+33 (0)6 43 46 13 39
15 Le Palais des Fleurs,
74 Boulevard Raymond Poincare,
06160 Juan les Pins, FRANCE.
http://www.watt.com.my
+6 017 2071591
|