This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] Warn users about mismatched PID namespaces


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Linux supports multiple "PID namespaces". Processes in different PID
namespaces have different views of the system process list. Sometimes,
a single process can appear in more than one PID namespace, but with a
different PID in each. When GDB and its target are in different PID
namespaces, various features can break due to the mismatch between
what the target believes its PID to be and what GDB believes its PID
to be. The most visible broken functionality is thread enumeration
silently failing.

This patch explicitly warns users against trying to debug across PID
namespaces.

The patch introduced no new failures in my test suite run on an x86_64
installation of Ubuntu 14.10. It doesn't include a test: writing an
automated test that exercises this code would be very involved because
CLONE_NEWNS requires CAP_SYS_ADMIN; the easier way to reproduce the
problem is to start a new lxc container.

2014-10-30  Daniel Colascione  <dancol@dancol.org>

	Warn about cross-PID-namespace debugging.
	* nat/linux-procfs.h (linux_proc_pid_get_ns): New prototype.
	* nat/linux-procfs.c (linux_proc_pid_get_ns): New function.
	* linux-thread-db.c (thread_db_inferior_created): Check for
	mismatched PID namespaces.

diff --git a/gdb/linux-thread-db.c b/gdb/linux-thread-db.c
index 352fac1..4089417 100644
- --- a/gdb/linux-thread-db.c
+++ b/gdb/linux-thread-db.c
@@ -1223,6 +1223,25 @@ thread_db_new_objfile (struct objfile *objfile)
 static void
 thread_db_inferior_created (struct target_ops *target, int from_tty)
 {
+  /* If the child is in a different PID namespace, its idea of its PID
+     will differ from our idea of its PID.  When we scan the child's
+     thread list, we'll mistakenly think it has no threads since the
+     thread PID fields won't match the PID we give to
+     libthread_db.  */
+  char *our_pid_ns = linux_proc_pid_get_ns (getpid (), "pid");
+  char *inferior_pid_ns = linux_proc_pid_get_ns (
+    ptid_get_pid (inferior_ptid), "pid");
+
+  if (our_pid_ns != NULL && inferior_pid_ns != NULL &&
+      strcmp (our_pid_ns, inferior_pid_ns) != 0)
+    {
+      warning (_ ("Target and debugger are in different PID namespaces; "
+		  "thread lists and other data are likely unreliable"));
+    }
+
+  xfree (our_pid_ns);
+  xfree (inferior_pid_ns);
+
   check_for_thread_db ();
 }

diff --git a/gdb/nat/linux-procfs.c b/gdb/nat/linux-procfs.c
index 30797da..8efccba 100644
- --- a/gdb/nat/linux-procfs.c
+++ b/gdb/nat/linux-procfs.c
@@ -113,3 +113,22 @@ linux_proc_pid_is_zombie (pid_t pid)
 {
   return linux_proc_pid_has_state (pid, "Z (zombie)");
 }
+
+/* See linux-procfs.h declaration.  */
+
+char*
+linux_proc_pid_get_ns (pid_t pid, const char *ns)
+{
+  char buf[100];
+  char nsval[64];
+  int ret;
+  snprintf (buf, sizeof (buf), "/proc/%d/ns/%s", (int) pid, ns);
+  ret = readlink (buf, nsval, sizeof (nsval));
+  if (0 < ret && ret < sizeof (nsval))
+    {
+      nsval[ret] = '\0';
+      return xstrdup (nsval);
+    }
+
+  return NULL;
+}
diff --git a/gdb/nat/linux-procfs.h b/gdb/nat/linux-procfs.h
index d13fff7..e4f301f 100644
- --- a/gdb/nat/linux-procfs.h
+++ b/gdb/nat/linux-procfs.h
@@ -40,4 +40,10 @@ extern int linux_proc_pid_is_stopped (pid_t pid);

 extern int linux_proc_pid_is_zombie (pid_t pid);

+/* Return an opaque string identifying PID's NS namespace or NULL if
+ * the information is unavailable.  The returned string must be
+ * released with xfree.  */
+
+extern char* linux_proc_pid_get_ns (pid_t pid, const char *ns);
+
 #endif /* COMMON_LINUX_PROCFS_H */

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUUat+AAoJEN4WImmbpWBlj78P/i090ErNhO9EwA5BbcpEnRsz
J9Zrjyr2TPKvDyeMB7ZWqU+YlXRbG0vzVoagyMxek6Qru2n6EnVPJIypriefim1D
scDQ0qkNPoK67T9/14O5xHVEgDl6ABjWV+3JWD7XXFS2YPpd2zQnCioW5dFIbtcw
0Ezj6TmBtOTHOXRGUTKi8USYUtF8U2qnH/Nf+p0TOGOJqMGJHo8LeDqWSTE9kIE6
z7xjsJKuzMrwnprtDKUH6rqlgjjQH9uTlF5XZ6hTV98+CHGPkB3NyAEYytW0FF0y
yTKqjmb+8QYMNZ75fJuP7PAvnbOU6vAfjZZu4CIoNDgDwCZcPtp3NC9TNxmZK5FV
xk3gEBBY0IxYNEqH8qiV2irK3OAgotxUdJSMLQEcOoId40bIIs4rkGbpBq4jW+2A
Rkfrman5L+5zHWRyamzmd/8aoh3zu+mNDeXzzc0AIKcw0hXv+aBu+eQ7keajvoD7
yAqCTzit3uaYsxYbPNjta1d39uB/xiCrs1Vm8ZKJuRxqcHB2gw89+QC+NEEWohkd
lS3rSyP4r65pHCQOdRnKu401/uJi6ouwxPb7mbw+MXFXi369U7vKoZ82uuv6N3uk
TnhnC8eQIZijflAkG+OlZQyi+EuzwPC++e9Ugq15vtyqBtCwnDlh+AWTvWVosKDB
rzNT57A9vmTcRg3CNXz/
=NLmY
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]