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不起作用，儀器啓動/停止，因此按需分析是不可能的。
可能是什麼問題？