|
From: <sv...@va...> - 2008-03-17 16:23:50
|
Author: sewardj
Date: 2008-03-17 16:23:54 +0000 (Mon, 17 Mar 2008)
New Revision: 7723
Log:
Kludgily fix a regression caused by the recent DATASYMS merge, which
caused V to hang when running Amarok in KDE 3.5.X.
Modified:
trunk/coregrind/m_debuginfo/debuginfo.c
Modified: trunk/coregrind/m_debuginfo/debuginfo.c
===================================================================
--- trunk/coregrind/m_debuginfo/debuginfo.c 2008-03-17 15:25:50 UTC (rev 7722)
+++ trunk/coregrind/m_debuginfo/debuginfo.c 2008-03-17 16:23:54 UTC (rev 7723)
@@ -520,6 +520,35 @@
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));
|