Question

在Android上，运行带有--vgdb=yes的valgrind 3.9.0会创建一个FIFO管道，它应该监听vgdb命令（以及另一个反向管道和一块共享内存）。但是，vgdb instrumentation on之类的命令会永远挂起。

这是在带有Android 4.0.3的armv7模拟器（据报道可以在README.android上运行）和基于Android 4.3.1的Cyanogenmod的Galaxy Note II上进行测试
valgrind由export HWKIND=generic和--with-tmpdir=/data/local/Inst构建;所有其他选项均根据README.android文件
这两个设备都已植根并运行不安全的adbd＆＃39>
测试了两个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 (vchtchetkine@vc-irv.irv.corp.google.com) (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目录中有效，因为以下工作原理：

在/data/local/Inst内的根shell中：

# 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不起作用，因此无法启动/停止仪表并因此进行按需分析。

可能是什么问题？

Answer 1

这是android上vgdb的已知限制。 vgdb-invoker-ptrace.c应该在android上移植。

参见https://bugs.kde.org/show_bug.cgi?id=338977 了解更多详情

Android上的valgrind不会听vgdb

1 个答案: