|
From: Arthur L. <lam...@gm...> - 2013-07-19 12:33:23
|
Hi, my dev environment is : - uClibc-0.9.30 - Openwrt backfire version - Valgrind 3.8.1 - ARCH : MIPS32 - Linux 2.6.28.8 I am trying to use valgrind to find memory leak and error on memory usage on my program. I have two issues with valgrind on my target. First when I run any binary without any particular option I get an error. Here for example I use a basic helloworld which just malloc and print a char* : ___________________________ root@OpenWrt:~# valgrind /opt/data/helloworld ==794== Memcheck, a memory error detector ==794== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==794== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==794== Command: /opt/data/helloworld ==794== ==794== ==794== Process terminating with default action of signal 11 (SIGSEGV) ==794== Access not within mapped region at address 0x5554 ==794== at 0x4004444: ??? (in /lib/ld-uClibc-0.9.30.so) ==794== by 0x4000ACC: _start (in /lib/ld-uClibc-0.9.30.so) ==794== If you believe this happened as a result of a stack ==794== overflow in your program's main thread (unlikely but ==794== possible), you can try to increase the size of the ==794== main thread stack using the --main-stacksize= flag. ==794== The main thread stack size used in this run was 8388608. valgrind: m_scheduler/scheduler.c:923 (run_thread_for_a_while): Assertion 'two_words[0] == 0 && two_words[1] == 0' failed. ==794== at 0x3803F39C: ??? (in /usr/lib/valgrind/memcheck-mips32-linux) ==794== by 0x3803F2C8: ??? (in /usr/lib/valgrind/memcheck-mips32-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==794== at 0x4004444: ??? (in /lib/ld-uClibc-0.9.30.so) ==794== by 0x4000ACC: _start (in /lib/ld-uClibc-0.9.30.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. _____________________________________ Another bug was talking about this issue but with glibc : https://bugs.kde.org/show_bug.cgi?id=307141. Not sure, but by reading this bug, the issue was fixed by using an up to date revision of gcc. Do I have the same trouble here ? Secondly, my main program is working fine without valgrind. When I run it with valgrind, I get a segfault after few seconds which can be normal. I get a vgcore file. I am not able to use it on gdb or understand the meaning of the output of valgrind. I had already use core file generated by my binary without vallgrind after running ulimit -c unlimited command but impossible to use specific core file from valgrind : root@OpenWrt:~# valgrind --track-origins=yes --num-callers=32 --leak-check=full --workaround-gcc296-bugs=yes XXXXX ==795== Memcheck, a memory error detector ==795== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==795== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==795== Command: XXXXX ==795== ==795== Conditional jump or move depends on uninitialised value(s) ==795== at 0x40044B0: ??? (in /lib/ld-uClibc-0.9.30.so) ==795== by 0x4000ACC: _start (in /lib/ld-uClibc-0.9.30.so) ==795== Uninitialised value was created by a stack allocation ==795== at 0x4004410: ??? (in /lib/ld-uClibc-0.9.30.so) ==795== ==795== Warning: client switching stacks? SP change: 0x7eff01c8 --> 0x3c2 ==795== to suppress, use: --max-stackframe=2130640390 or greater ==795== Invalid write of size 4 ==795== at 0x4E7ACD0: ??? (in /lib/libuClibc-0.9.30.so) ==795== by 0x4E7CE2C: re_search_2 (in /lib/libuClibc-0.9.30.so) ==795== Address 0x7eff00dc is on thread 1's stack ==795== ==795== Invalid write of size 4 ==795== at 0x4E7ACD4: ??? (in /lib/libuClibc-0.9.30.so) ==795== by 0x4E7CE2C: re_search_2 (in /lib/libuClibc-0.9.30.so) ==795== Address 0x7eff011c is on thread 1's stack ==795== ==795== Invalid write of size 4 ==795== at 0x4E7ACD8: ??? (in /lib/libuClibc-0.9.30.so) ==795== by 0x4E7CE2C: re_search_2 (in /lib/libuClibc-0.9.30.so) ==795== Address 0x7eff015c is on thread 1's stack ==795== ==795== Invalid write of size 4 ==795== at 0x4E7ACDC: ??? (in /lib/libuClibc-0.9.30.so) ==795== by 0x4E7CE2C: re_search_2 (in /lib/libuClibc-0.9.30.so) ==795== Address 0x7eff019c is on thread 1's stack ==795== ==795== Invalid read of size 4 ==795== at 0x4E7ACF0: ??? (in /lib/libuClibc-0.9.30.so) ==795== by 0x4E7CE2C: re_search_2 (in /lib/libuClibc-0.9.30.so) ==795== Address 0x7eff001c is on thread 1's stack ==795== ==795== Invalid write of size 4 ==795== at 0x4E7AD04: ??? (in /lib/libuClibc-0.9.30.so) ==795== by 0x4E7CE2C: re_search_2 (in /lib/libuClibc-0.9.30.so) ==795== Address 0x7eff001c is on thread 1's stack ==795== ==795== Can't extend stack to 0xfffffdc8 during signal delivery for thread 1: ==795== no stack segment ==795== ==795== Process terminating with default action of signal 11 (SIGSEGV) ==795== Access not within mapped region at address 0xFFFFFDC8 ==795== at 0x4831160: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-mips32-linux.so) ==795== If you believe this happened as a result of a stack ==795== overflow in your program's main thread (unlikely but ==795== possible), you can try to increase the size of the ==795== main thread stack using the --main-stacksize= flag. ==795== The main thread stack size used in this run was 2088960. ==795== ==795== Process terminating with default action of signal 11 (SIGSEGV) ==795== General Protection Fault ==795== at 0x4816740: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-mips32-linux.so) ==795== ==795== HEAP SUMMARY: ==795== in use at exit: 163,456 bytes in 1,398 blocks ==795== total heap usage: 5,688 allocs, 4,290 frees, 597,875 bytes allocated ==795== [...] ==795== ==795== LEAK SUMMARY: ==795== definitely lost: 0 bytes in 0 blocks ==795== indirectly lost: 0 bytes in 0 blocks ==795== possibly lost: 39,375 bytes in 530 blocks ==795== still reachable: 124,081 bytes in 868 blocks ==795== suppressed: 0 bytes in 0 blocks ==795== Reachable blocks (those to which a pointer was found) are not shown. ==795== To see them, rerun with: --leak-check=full --show-reachable=yes ==795== ==795== For counts of detected and suppressed errors, rerun with: -v ==795== ERROR SUMMARY: 85 errors from 15 contexts (suppressed: 0 from 0) Segmentation fault Thanks, - Arthur LAMBERT |