valgrind 3.11.0 stuck after redirecting "memcpy" and does not start my application. By using "top -H", I can see memcheck-ppc32- costs about 70% cpu. ==1404== Memcheck, a memory error detector ==1404== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==1404== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==1404== Command: /root/bin/bootenv /dev/mtd0 ==1404== --1404-- Valgrind options: --1404-- -v --1404-- Contents of /proc/version: --1404-- Linux version 3.2.14 (pwang@ipsr-dev) (gcc version 4.6.4 (crosstool-NG crosstool-ng-1.22.0) ) #1 Fri Jun 10 15:19:58 EDT 2016 --1404-- --1404-- Arch and hwcaps: PPC32, BigEndian, ppc32-int-flt-GX --1404-- Page sizes: currently 4096, max supported 65536 --1404-- Valgrind library directory: /usr/lib/valgrind --1404-- Reading syms from /lib/ld-2.18.so --1404-- Reading syms from /root/bin/bootenv --1404-- object doesn't have a symbol table --1404-- Reading syms from /usr/lib/valgrind/memcheck-ppc32-linux --1404-- object doesn't have a symbol table --1404-- object doesn't have a dynamic symbol table --1404-- Scheduler: using generic scheduler lock implementation. --1404-- Reading suppressions file: /usr/lib/valgrind/default.supp ==1404== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-1404-by-root-on-??? ==1404== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-1404-by-root-on-??? ==1404== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-1404-by-root-on-??? ==1404== ==1404== TO CONTROL THIS PROCESS USING vgdb (which you probably ==1404== don't want to do, unless you know exactly what you're doing, ==1404== or are doing some strange experiment): ==1404== /usr/lib/valgrind/../../bin/vgdb --pid=1404 ...command... ==1404== ==1404== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==1404== /path/to/gdb /root/bin/bootenv ==1404== and then give GDB the following command ==1404== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=1404 ==1404== --pid is optional if only one valgrind process is running ==1404== --1404-- REDIR: 0x401a248 (ld.so.1:strlen) redirected to 0x3806fc3c (???) --1404-- REDIR: 0x401a080 (ld.so.1:strcmp) redirected to 0x3806fc64 (???) --1404-- REDIR: 0x4019fa8 (ld.so.1:index) redirected to 0x3806fcd8 (???) --1404-- Reading syms from /usr/lib/valgrind/vgpreload_core-ppc32-linux.so --1404-- object doesn't have a symbol table --1404-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-ppc32-linux.so --1404-- object doesn't have a symbol table --1404-- REDIR: 0x401ace4 (ld.so.1:mempcpy) redirected to 0xffbb644 (mempcpy) Reproducible: Always Steps to Reproduce: 1. Pick up any application on my Linux platform 2. type "valgrind -v myProgram" Actual Results: Valgrind stuck after outputting message below. --1397-- REDIR: 0x401ace4 (ld.so.1:mempcpy) redirected to 0xffbb644 (mempcpy) I am using buildroot 2016.02 for building kernel and all the applications including valgrind 3.11.0
With just the provided info, there is not much we can say. Several things can be done to investigate what goes wrong: 1. add some traces e.g. start valgrind with -v -v -v -d -d -d 2. assuming that your application is started up, you can investigate what it is doing under valgrind using valgrind+vgdb + gdb. 3. finally, you could try to debug valgrind itself by using gdb and attach to the memcheck-ppc32 program, do a backtrace and report what it does
Created attachment 99955 [details] valgrind prints
thanks for the quick reply. I tried with -v -v -v -d -d -d and you can see much details in attached "valgrind prints.txt". However, it was no help and last prints is still "redirected to 0xffbb644 (mempcpy) " and then valgrind just stopped printing anything. I am sure that my application was not started by valgrind. Actually, I tried many application on my linux platform and none of them worked fine with valgrind. Valgrind just printed "redirected to 0xffbb644 (mempcpy)" as the last message and was stuck there without launching my applications. I also tried debugging valgrind with gdb and the stack call trace is below. I have no idea what's going on. Attaching to process 1399 Reading symbols from /usr/lib/valgrind/memcheck-ppc32-linux...done. 0x6337d3d0 in ?? () (gdb) t a a bt #0 0x6337d3d0 in ?? () #1 0x3809f8d4 in run_thread_for_a_while (two_words=0x62930020, dispatchCtrP=0x0, tid=1664228688, alt_host_addr=1658819056, use_alt_host_addr=<optimized out>) at m_scheduler/scheduler.c:947 #2 0x00000000 in ?? ()
Effectively, there is not a lot more info. It looks however that (some) user level code is being executed, as the user stack is being extended. So, you might try to attach to the valgrind gdb server by doing gdb <your executable> and then (gdb) target remote | /usr/lib/valgrind/../../bin/vgdb --pid=XXXXX (as instructed by gdb). Assuming the above does not work or give any info, you might try with the none tool: --tool=none Also maybe try with the smallest simplest executable you have (maybe and "hello world" program, or date, or similar). Other possible options to trace are --trace-signals=yes --trace-syscalls=yes --trace-flags=00100000 --trace-notbelow=1 Just to see if something happens. But for sure, we shoot in the dark with the above
NB/ when adding additional trace, still keep the -v -v -v -d -d -d
Peter, can you re-run with --trace-signals=yes --trace-syscalls=yes --trace-flags=10000000 --trace-notbelow=1 ? That might give some more information. What CPU is this running on?
What CPU are you running on here?
Freescale MPC8377