2
在Android，的valgrind运行3.9.0与--vgdb=yes创建一个FIFO管应该听vgdb命令（与另一管的相反方向和一块共享存储器的一起）。但是，诸如vgdb instrumentation on之类的命令只是永远挂起。的valgrind Android上不听vgdb
- 这是采用Android 4.0.3（正报上README.android工作）的ARMv7的仿真测试，并在的Galaxy Note II采用Android 4.3.1基于CyanogenMod的
- Valgrind是建有
export HWKIND=generic和--with-tmpdir=/data/local/Inst;所有其他选项都是根据README.android文件 - 这两款器件都植根并运行不安全adbd的
- 两个Valgrind的建立进行了测试，其中一个NDK-R6建成一个与NDK-r9d。其结果是在所有的配置
- 这两种设备都能够Valgrind的运行相同但既不运行听vgdb
作为参考，Valgrind的命令和它的输出如下：
# ./valgrind -v -v -v --vgdb=yes sleep 1000
==3640== Memcheck, a memory error detector
==3640== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3640== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==3640== Command: sleep 1000
==3640==
--3640-- Valgrind options:
--3640-- -v
--3640-- -v
--3640-- -v
--3640-- --vgdb=yes
--3640-- Contents of /proc/version:
--3640-- Linux version 2.6.29-g46b05b2 ([email protected]) (gcc version 4.4.3 (GCC)) #28 Thu Nov 17 06:39:36 PST 2011
--3640-- Arch and hwcaps: ARM, ARMv7-vfp-neon
--3640-- Page sizes: currently 4096, max supported 4096
--3640-- Valgrind library directory: /data/local/Inst/lib/valgrind
--3640-- TT/TC: VG_(init_tt_tc) (startup of code management)
--3640-- TT/TC: cache: 6 sectors of 27597024 bytes each = 165582144 total
--3640-- TT/TC: table: 6 tables of 11531696 bytes each = 69190176 total
--3640-- TT/TC: table: 65521 entries each = 393126 total entries max occupancy 255528 (65%)
--3640-- Reading syms from /system/xbin/busybox
--3640-- svma 0x0000008120, avma 0x0000008120
--3640-- object doesn't have a symbol table
--3640-- object doesn't have a dynamic symbol table
--3640-- Reading syms from /data/local/Inst/lib/valgrind/memcheck-arm-linux
--3640-- svma 0x0038000000, avma 0x0038000000
--3640-- object doesn't have a dynamic symbol table
--3640-- Scheduler: using generic scheduler lock implementation.
--3640-- Reading suppressions file: /data/local/Inst/lib/valgrind/default.supp
==3640== embedded gdbserver: reading from /data/local/Inst/vgdb-pipe-from-vgdb-to-3640-by-???-on-???
==3640== embedded gdbserver: writing to /data/local/Inst/vgdb-pipe-to-vgdb-from-3640-by-???-on-???
==3640== embedded gdbserver: shared mem /data/local/Inst/vgdb-pipe-shared-mem-vgdb-3640-by-???-on-???
==3640==
==3640== TO CONTROL THIS PROCESS USING vgdb (which you probably
==3640== don't want to do, unless you know exactly what you're doing,
==3640== or are doing some strange experiment):
==3640== /data/local/Inst/lib/valgrind/../../bin/vgdb --pid=3640 ...command...
==3640==
==3640== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==3640== /path/to/gdb sleep
==3640== and then give GDB the following command
==3640== target remote | /data/local/Inst/lib/valgrind/../../bin/vgdb --pid=3640
==3640== --pid is optional if only one valgrind process is running
==3640==
--3640-- TT/TC: initialise sector 0
该vgdb命令（没有输出，直到它杀死）：
# ./vgdb instrumentation on
^Csyscall failed: Interrupted system call
error opening /data/local/Inst/vgdb-pipe-to-vgdb-from-3640-by-???-on-??? read cmd result from pid
一些注意事项：
在真实设备上，HOSTNAME和USER不是？但实际上是
t0lte和root正确。这可能与这个问题无关。我敢肯定，FIFO管道在上述
/data/local/Inst目录工作，因为以下工作：
在一个root shell里面/data/local/Inst：
# mkfifo examplepipe
# echo message > examplepipe
... command exits after the pipe is read in another shell ...
#
在另一个shell：
# cat examplepipe
message
我也相信vgdb是找到Valgrind的实例，因为它不报告
FIFO not found错误。我在这一点上vgdb原因挂起猜测是Valgrind的不听管的某些原因。本身
Valgrind的操作如预期运行。 Callgrind输出产生等。但由于vgdb不起作用，仪器启动/停止，因此按需分析是不可能的。
可能是什么问题？