Kludgily fix a regression caused by the recent DATASYMS merge, which

caused V to hang when running Amarok in KDE 3.5.X.

git-svn-id: svn://svn.valgrind.org/valgrind/trunk@7723

diff --git a/coregrind/m_debuginfo/debuginfo.c b/coregrind/m_debuginfo/debuginfo.c
index a37aaa67efb29a2b5d169e47a0dace484c217252..b1a3e817e4d36f3d41276c3ec89bd3dee316aba9 100644 (file)
--- a/coregrind/m_debuginfo/debuginfo.c
+++ b/coregrind/m_debuginfo/debuginfo.c
@@ -520,6 +520,35 @@ void VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV )
    if (debug)
       VG_(printf)("di_notify_mmap-2: %s\n", filename);
 
+   /* XXXX begin KLUDGE */
+   /* Skip filenames in /dev/.  Don't even bother to try opening them.
+      Why?
+
+      Suppose the client opens and then mmaps the file specified by
+      'filename' and puts some kind of lock on it, so nobody else can
+      open it.  If we now try to open it to peer at the ELF header,
+      the system can hang, because the VG_(open) call blocks.
+      Precisely this happed when running Amarok, which opened and then
+      mmap'd /dev/snd/pcmC0D0c.
+
+      A clean(er) solution is to open the file with VKI_O_NONBLOCK, so
+      that if it is locked, we simply fail immediately and don't hang
+      the whole system.  But "man 2 open" gives only a sketchy
+      description of the resulting file semantics.  So for the
+      meantime, just skip files in /dev/ as (1) they are likely to be
+      subject to wierd-ass locking stuff, and (2) they won't contain
+      useful debug info anyway.
+
+      But that's a kludge; in principle the same problem could occur
+      with *any* file.
+   */
+   if (0 == VG_(strncmp)(filename, "/dev/", 5)) {
+      if (debug)
+         VG_(printf)("di_notify_mmap-2: skipping %s\n", filename);
+      return;
+   }
+   /* XXXX end KLUDGE */
+
    /* Peer at the first few bytes of the file, to see if it is an ELF
       object file. */
    VG_(memset)(buf1k, 0, sizeof(buf1k));