Bug 338977

On Android, running valgrind with `--vgdb=yes` creates a FIFO pipe that should listen to vgdb commands (along with another pipe for the reverse direction and a piece of shared memory). However, a command such as `vgdb instrumentation on` just hangs forever. 

This is tested on an armv7 emulator with Android 4.0.3 (which is reported to work) and on a Galaxy Note II with Android 4.3.1 based Cyanogenmod. Both devices were rooted and were running insecure adbd's. Two valgrind builds were tested, one built with ndk-r6 and one with ndk-r9d. The result is the same on all configurations. Both devices are able to run valgrind but neither runs listen to vgdb. 

For reference, the valgrind command and its output are as follows: 

```
# ./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
```

The vgdb command is (there is no output until it's killed):

```
# ./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
```

Reproducible: Always

Steps to Reproduce:
1. Build valgrind with `export HWKIND=generic` and `--with-tmpdir=/data/local/Inst`
2. Run `valgrind --vgdb=yes --tool=callgrind sleep 1000`
3. In another terminal, run `vgdb instrumentation on`

Actual Results:  
vgdb hangs forever until killed.

Expected Results:  
vgdb should have reported:
```
sending command instrumentation on to pid 3640
```

Then, valgrind should have reported:
```
...
==3640== Remote side has terminated connection.  GDBserver will reopen the connection.
==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==   /usr/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 | /usr/lib/valgrind/../../bin/vgdb --pid=3640
==3640== --pid is optional if only one valgrind process is running
==3640== 
```

- On the real device, the HOSTNAME and USER are not ??? but actually are `t0lte` and `root` properly. It probably has nothing to do with this issue. 

- I'm sure that FIFO piping works in the aforementioned `/data/local/Inst` directory because the following works:
```
# mkfifo examplepipe
# echo message > examplepipe
... command exits after the pipe is read in another shell ...
# 
```

In another shell:
```
# cat examplepipe
message
```

- I'm also sure that vgdb is finding the valgrind instance because it doesn't report `FIFO not found` error.

- I'm guessing at this point that the reason vgdb hangs is that valgrind does not listen to the pipe for some reason.