[Valgrind-users] Issue with assertion and vgcore by using valgrind on MIPS32

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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