What version of the product are you using? On what operating system?

32-bit Linux, tcmalloc 2.0, GCC 4.7.1, eglibc 2.13

Please provide any additional information below.

Whilst trying to debug a crash in heap-checker_unittest.sh, I came across some very
strange code in src/base/linuxthreads.cc, which attempts to detect whether a related
process is a fork or a thread by trying to determine whether the address spaces are
distinct.  The offending code is as follows (lines 446-458):

  if (sys_ptrace(PTRACE_PEEKDATA, pid, &i, &j) || i++ != j ||
      sys_ptrace(PTRACE_PEEKDATA, pid, &i, &j) || i   != j) {
    /* Address spaces are distinct, even though both
     * processes show the "marker". This is probably
     * a forked child process rather than a thread.
     */
    sys_ptrace_detach(pid);
    num_threads--;
    sig_num_threads = num_threads;
  } else {
    found_parent |= pid == ppid;
    added_entries++;
  }

As far as I can tell, what this is trying to do is peek at the other process's address
space to see if the memory at &i is the same as in the current process, then frob i,
and see whether &i in the other process changes as well.  This is broken for two reasons:

1. It appears to assume that the PTRACE_PEEKDATA will load the data at the address
in the 3rd argument, into the variable given as the 4th argument, and return 0 on success
(which will evaluate to false, and continue evaluating the statement after the ||).
 This is not true - according to the man page, the 4th argument is ignored, and the
*return value* is the data, with errno used to indicate success/failure.

2. Even if the PTRACE_PEEKDATA calls are fixed, the test can ever work as desired,
since i is a local variable and stack variables are always thread-local.  The data
at address &i in a related process is not guaranteed to be equal to i, regardless of
whether it is a fork or a thread.

As far as I can tell, the only reason it "works" is because the PTRACE_PEEKDATA calls
are failing, returning zero (which evaluates to false), and setting errno to EFAULT
(14), which is then reflected in the output from my failed test run:

  In main(): heap_check=local
  Thread finding failed with -1 errno=14
  Thread finding callback was interrupted or crashed; can't fix this
  ----
  FAIL: heap-checker_debug_unittest.sh

Please find attached a patch which uses a different approach, based on using the __WCLONE
option with waitpid().  From my testing, this appears to detect relatives correctly,
including the distinction between forks and processes, since the parent process - which
the code checks for as a sanity-check - is a "real" process, not a clone.

Unfortunately, this patch has not fixed my unit test failure, since the crash really
is within the callback, not the thread-finding routine.