In order to catch timeout events on fds which are readable and which

have been ioctl(TCSETA)'d with a VTIMEout, we appear to need to ask if
the fd is writable, for some reason.  Ask me not why.  Since this is
strange and potentially troublesome we only do it if the user asks
specially, by specifying --wierd-hacks=ioctl-VTIME.

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

diff --git a/cachegrind/docs/manual.html b/cachegrind/docs/manual.html
index d4fd738f652dbf9a29069dd326a534b268bfb8fc..8ada25fe201badbf5114b23a7fc832d57ef53189 100644 (file)
--- a/cachegrind/docs/manual.html
+++ b/cachegrind/docs/manual.html
@@ -562,7 +562,39 @@ follows:
   <li><code>--cachesim=no</code> [default]<br>
       <code>--cachesim=yes</code> <p>When enabled, turns off memory
       checking, and turns on cache profiling.  Cache profiling is
-      described in detail in <a href="#cache">Section 7</a>.  </li><p>
+      described in detail in <a href="#cache">Section 7</a>.
+      </li><br><p>
+
+  <li><code>--wierd-hacks=hack1,hack2,...</code>
+      Pass miscellaneous hints to Valgrind which slightly modify the
+      simulated behaviour in nonstandard or dangerous ways, possibly
+      to help the simulation of strange features.  By default no hacks
+      are enabled.  Use with caution!  Currently known hacks are:
+      <p>
+      <ul>
+      <li><code>ioctl-VTIME</code> Use this if you have a program
+          which sets readable file descriptors to have a timeout by
+          doing <code>ioctl</code> on them with a
+          <code>TCSETA</code>-style command <b>and</b> a non-zero
+          <code>VTIME</code> timeout value.  This is considered
+          potentially dangerous and therefore is not engaged by
+          default, because it is (remotely) conceivable that it could
+          cause threads doing <code>read</code> to incorrectly block
+          the entire process.
+          <p>
+          You probably want to try this one if you have a program
+          which unexpectedly blocks in a <code>read</code> from a file
+          descriptor which you know to have been messed with by
+          <code>ioctl</code>.  This could happen, for example, if the
+          descriptor is used to read input from some kind of screen
+          handling library.
+          <p>
+          To find out if your program is blocking unexpectedly in the
+          <code>read</code> system call, run with
+          <code>--trace-syscalls=yes</code> flag.
+      </ul>
+
+      </li><p>
 </ul>
 
 There are also some options for debugging Valgrind itself.  You

diff --git a/coregrind/docs/manual.html b/coregrind/docs/manual.html
index d4fd738f652dbf9a29069dd326a534b268bfb8fc..8ada25fe201badbf5114b23a7fc832d57ef53189 100644 (file)
--- a/coregrind/docs/manual.html
+++ b/coregrind/docs/manual.html
@@ -562,7 +562,39 @@ follows:
   <li><code>--cachesim=no</code> [default]<br>
       <code>--cachesim=yes</code> <p>When enabled, turns off memory
       checking, and turns on cache profiling.  Cache profiling is
-      described in detail in <a href="#cache">Section 7</a>.  </li><p>
+      described in detail in <a href="#cache">Section 7</a>.
+      </li><br><p>
+
+  <li><code>--wierd-hacks=hack1,hack2,...</code>
+      Pass miscellaneous hints to Valgrind which slightly modify the
+      simulated behaviour in nonstandard or dangerous ways, possibly
+      to help the simulation of strange features.  By default no hacks
+      are enabled.  Use with caution!  Currently known hacks are:
+      <p>
+      <ul>
+      <li><code>ioctl-VTIME</code> Use this if you have a program
+          which sets readable file descriptors to have a timeout by
+          doing <code>ioctl</code> on them with a
+          <code>TCSETA</code>-style command <b>and</b> a non-zero
+          <code>VTIME</code> timeout value.  This is considered
+          potentially dangerous and therefore is not engaged by
+          default, because it is (remotely) conceivable that it could
+          cause threads doing <code>read</code> to incorrectly block
+          the entire process.
+          <p>
+          You probably want to try this one if you have a program
+          which unexpectedly blocks in a <code>read</code> from a file
+          descriptor which you know to have been messed with by
+          <code>ioctl</code>.  This could happen, for example, if the
+          descriptor is used to read input from some kind of screen
+          handling library.
+          <p>
+          To find out if your program is blocking unexpectedly in the
+          <code>read</code> system call, run with
+          <code>--trace-syscalls=yes</code> flag.
+      </ul>
+
+      </li><p>
 </ul>
 
 There are also some options for debugging Valgrind itself.  You

diff --git a/coregrind/valgrind.in b/coregrind/valgrind.in
index b10f48795b6a18d69ddc25ab16ef563e6539d5e5..6cc9a544cc786f9e994d7819e3d6455396477458 100755 (executable)
--- a/coregrind/valgrind.in
+++ b/coregrind/valgrind.in
@@ -67,6 +67,7 @@ do
     --suppressions=*)       vgopts="$vgopts $arg"; shift;;
     --cachesim=yes)         vgopts="$vgopts $arg"; shift;;
     --cachesim=no)          vgopts="$vgopts $arg"; shift;;
+    --wierd-hacks=*)        vgopts="$vgopts $arg"; shift;;
 #   options for debugging Valgrind
     --sanity-level=*)       vgopts="$vgopts $arg"; shift;;
     --single-step=yes)      vgopts="$vgopts $arg"; shift;;
@@ -132,6 +133,9 @@ if [ $# = 0 ] || [ z"$dousage" = z1 ]; then
    echo "    --check-addrVs=no|yes     experimental lighterweight checking? [yes]"
    echo "                              yes == Valgrind's original behaviour"
    echo "    --cachesim=no|yes         do cache profiling? [no]"
+   echo "    --wierd-hacks=hack1,hack2,...  [no hacks selected]"
+   echo "         recognised hacks are: ioctl-VTIME"
+   echo ""
    echo
    echo "  options for debugging Valgrind itself are:"
    echo "    --sanity-level=<number>   level of sanity checking to do [1]"

diff --git a/coregrind/vg_include.h b/coregrind/vg_include.h
index d4622b28925e445b1db4229e7e1fb4009e695644..74bfa7d257c5d9cf6934f24e8646d7c6be699282 100644 (file)
--- a/coregrind/vg_include.h
+++ b/coregrind/vg_include.h
@@ -262,6 +262,8 @@ extern ULong VG_(clo_stop_after);
 extern Int   VG_(clo_dump_error);
 /* Number of parents of a backtrace.  Default: 8.  */
 extern Int   VG_(clo_backtrace_size);
+/* Engage miscellaneous wierd hacks needed for some progs. */
+extern Char* VG_(clo_wierd_hacks);
 
 
 /* ---------------------------------------------------------------------

diff --git a/coregrind/vg_main.c b/coregrind/vg_main.c
index 330068db79cce6ec00c9db613bc86d59b5cc74c6..05273b16327c4670cc680c59f650f63877196e2e 100644 (file)
--- a/coregrind/vg_main.c
+++ b/coregrind/vg_main.c
@@ -441,6 +441,7 @@ Int    VG_(clo_trace_pthread_level);
 ULong  VG_(clo_stop_after);
 Int    VG_(clo_dump_error);
 Int    VG_(clo_backtrace_size);
+Char*  VG_(clo_wierd_hacks);
 
 /* This Bool is needed by wrappers in vg_clientmalloc.c to decide how
    to behave.  Initially we say False. */
@@ -533,6 +534,7 @@ static void process_cmd_line_options ( void )
    VG_(clo_stop_after)       = 1000000000000LL;
    VG_(clo_dump_error)       = 0;
    VG_(clo_backtrace_size)   = 4;
+   VG_(clo_wierd_hacks)      = NULL;
 
    eventually_logfile_fd = VG_(clo_logfile_fd);
 
@@ -797,6 +799,9 @@ static void process_cmd_line_options ( void )
       else if (STREQ(argv[i], "--trace-pthread=all"))
          VG_(clo_trace_pthread_level) = 2;
 
+      else if (STREQN(14, argv[i], "--wierd-hacks="))
+         VG_(clo_wierd_hacks) = &argv[i][14];
+
       else if (STREQN(13, argv[i], "--stop-after="))
          VG_(clo_stop_after) = VG_(atoll)(&argv[i][13]);
 

diff --git a/coregrind/vg_mylibc.c b/coregrind/vg_mylibc.c
index fec258af74b86c02d256b0a6fbda6e59d7fa10aa..f42ba9400b606679f7dfb696a26f9aae449739a4 100644 (file)
--- a/coregrind/vg_mylibc.c
+++ b/coregrind/vg_mylibc.c
@@ -740,7 +740,10 @@ Int VG_(strncmp_ws) ( const Char* s1, const Char* s2, Int nmax )
 
 Char* VG_(strstr) ( const Char* haystack, Char* needle )
 {
-   Int n = VG_(strlen)(needle);
+   Int n; 
+   if (haystack == NULL)
+      return NULL;
+   n = VG_(strlen)(needle);
    while (True) {
       if (haystack[0] == 0) 
          return NULL;

diff --git a/coregrind/vg_scheduler.c b/coregrind/vg_scheduler.c
index 79056e7edfe889f4099bdd2081876e0d4c3cf800..88cbe3e747c5c2fca3bb4d2ffd159952d147e54d 100644 (file)
--- a/coregrind/vg_scheduler.c
+++ b/coregrind/vg_scheduler.c
@@ -972,7 +972,15 @@ void poll_for_ready_fds ( void )
       vg_assert(is_valid_tid(tid));
       syscall_no = vg_waiting_fds[i].syscall_no;
       switch (syscall_no) {
-         case __NR_read: 
+         case __NR_read:
+            /* In order to catch timeout events on fds which are
+               readable and which have been ioctl(TCSETA)'d with a
+               VTIMEout, we appear to need to ask if the fd is
+               writable, for some reason.  Ask me not why.  Since this
+               is strange and potentially troublesome we only do it if
+               the user asks specially. */
+            if (VG_(strstr)(VG_(clo_wierd_hacks), "ioctl-VTIME") != NULL)
+               VKI_FD_SET(fd, &writefds);
             VKI_FD_SET(fd, &readfds); break;
          case __NR_write: 
             VKI_FD_SET(fd, &writefds); break;

diff --git a/docs/manual.html b/docs/manual.html
index d4fd738f652dbf9a29069dd326a534b268bfb8fc..8ada25fe201badbf5114b23a7fc832d57ef53189 100644 (file)
--- a/docs/manual.html
+++ b/docs/manual.html
@@ -562,7 +562,39 @@ follows:
   <li><code>--cachesim=no</code> [default]<br>
       <code>--cachesim=yes</code> <p>When enabled, turns off memory
       checking, and turns on cache profiling.  Cache profiling is
-      described in detail in <a href="#cache">Section 7</a>.  </li><p>
+      described in detail in <a href="#cache">Section 7</a>.
+      </li><br><p>
+
+  <li><code>--wierd-hacks=hack1,hack2,...</code>
+      Pass miscellaneous hints to Valgrind which slightly modify the
+      simulated behaviour in nonstandard or dangerous ways, possibly
+      to help the simulation of strange features.  By default no hacks
+      are enabled.  Use with caution!  Currently known hacks are:
+      <p>
+      <ul>
+      <li><code>ioctl-VTIME</code> Use this if you have a program
+          which sets readable file descriptors to have a timeout by
+          doing <code>ioctl</code> on them with a
+          <code>TCSETA</code>-style command <b>and</b> a non-zero
+          <code>VTIME</code> timeout value.  This is considered
+          potentially dangerous and therefore is not engaged by
+          default, because it is (remotely) conceivable that it could
+          cause threads doing <code>read</code> to incorrectly block
+          the entire process.
+          <p>
+          You probably want to try this one if you have a program
+          which unexpectedly blocks in a <code>read</code> from a file
+          descriptor which you know to have been messed with by
+          <code>ioctl</code>.  This could happen, for example, if the
+          descriptor is used to read input from some kind of screen
+          handling library.
+          <p>
+          To find out if your program is blocking unexpectedly in the
+          <code>read</code> system call, run with
+          <code>--trace-syscalls=yes</code> flag.
+      </ul>
+
+      </li><p>
 </ul>
 
 There are also some options for debugging Valgrind itself.  You

diff --git a/memcheck/docs/manual.html b/memcheck/docs/manual.html
index d4fd738f652dbf9a29069dd326a534b268bfb8fc..8ada25fe201badbf5114b23a7fc832d57ef53189 100644 (file)
--- a/memcheck/docs/manual.html
+++ b/memcheck/docs/manual.html
@@ -562,7 +562,39 @@ follows:
   <li><code>--cachesim=no</code> [default]<br>
       <code>--cachesim=yes</code> <p>When enabled, turns off memory
       checking, and turns on cache profiling.  Cache profiling is
-      described in detail in <a href="#cache">Section 7</a>.  </li><p>
+      described in detail in <a href="#cache">Section 7</a>.
+      </li><br><p>
+
+  <li><code>--wierd-hacks=hack1,hack2,...</code>
+      Pass miscellaneous hints to Valgrind which slightly modify the
+      simulated behaviour in nonstandard or dangerous ways, possibly
+      to help the simulation of strange features.  By default no hacks
+      are enabled.  Use with caution!  Currently known hacks are:
+      <p>
+      <ul>
+      <li><code>ioctl-VTIME</code> Use this if you have a program
+          which sets readable file descriptors to have a timeout by
+          doing <code>ioctl</code> on them with a
+          <code>TCSETA</code>-style command <b>and</b> a non-zero
+          <code>VTIME</code> timeout value.  This is considered
+          potentially dangerous and therefore is not engaged by
+          default, because it is (remotely) conceivable that it could
+          cause threads doing <code>read</code> to incorrectly block
+          the entire process.
+          <p>
+          You probably want to try this one if you have a program
+          which unexpectedly blocks in a <code>read</code> from a file
+          descriptor which you know to have been messed with by
+          <code>ioctl</code>.  This could happen, for example, if the
+          descriptor is used to read input from some kind of screen
+          handling library.
+          <p>
+          To find out if your program is blocking unexpectedly in the
+          <code>read</code> system call, run with
+          <code>--trace-syscalls=yes</code> flag.
+      </ul>
+
+      </li><p>
 </ul>
 
 There are also some options for debugging Valgrind itself.  You

diff --git a/valgrind.in b/valgrind.in
index b10f48795b6a18d69ddc25ab16ef563e6539d5e5..6cc9a544cc786f9e994d7819e3d6455396477458 100755 (executable)
--- a/valgrind.in
+++ b/valgrind.in
@@ -67,6 +67,7 @@ do
     --suppressions=*)       vgopts="$vgopts $arg"; shift;;
     --cachesim=yes)         vgopts="$vgopts $arg"; shift;;
     --cachesim=no)          vgopts="$vgopts $arg"; shift;;
+    --wierd-hacks=*)        vgopts="$vgopts $arg"; shift;;
 #   options for debugging Valgrind
     --sanity-level=*)       vgopts="$vgopts $arg"; shift;;
     --single-step=yes)      vgopts="$vgopts $arg"; shift;;
@@ -132,6 +133,9 @@ if [ $# = 0 ] || [ z"$dousage" = z1 ]; then
    echo "    --check-addrVs=no|yes     experimental lighterweight checking? [yes]"
    echo "                              yes == Valgrind's original behaviour"
    echo "    --cachesim=no|yes         do cache profiling? [no]"
+   echo "    --wierd-hacks=hack1,hack2,...  [no hacks selected]"
+   echo "         recognised hacks are: ioctl-VTIME"
+   echo ""
    echo
    echo "  options for debugging Valgrind itself are:"
    echo "    --sanity-level=<number>   level of sanity checking to do [1]"

diff --git a/vg_include.h b/vg_include.h
index d4622b28925e445b1db4229e7e1fb4009e695644..74bfa7d257c5d9cf6934f24e8646d7c6be699282 100644 (file)
--- a/vg_include.h
+++ b/vg_include.h
@@ -262,6 +262,8 @@ extern ULong VG_(clo_stop_after);
 extern Int   VG_(clo_dump_error);
 /* Number of parents of a backtrace.  Default: 8.  */
 extern Int   VG_(clo_backtrace_size);
+/* Engage miscellaneous wierd hacks needed for some progs. */
+extern Char* VG_(clo_wierd_hacks);
 
 
 /* ---------------------------------------------------------------------

diff --git a/vg_main.c b/vg_main.c
index 330068db79cce6ec00c9db613bc86d59b5cc74c6..05273b16327c4670cc680c59f650f63877196e2e 100644 (file)
--- a/vg_main.c
+++ b/vg_main.c
@@ -441,6 +441,7 @@ Int    VG_(clo_trace_pthread_level);
 ULong  VG_(clo_stop_after);
 Int    VG_(clo_dump_error);
 Int    VG_(clo_backtrace_size);
+Char*  VG_(clo_wierd_hacks);
 
 /* This Bool is needed by wrappers in vg_clientmalloc.c to decide how
    to behave.  Initially we say False. */
@@ -533,6 +534,7 @@ static void process_cmd_line_options ( void )
    VG_(clo_stop_after)       = 1000000000000LL;
    VG_(clo_dump_error)       = 0;
    VG_(clo_backtrace_size)   = 4;
+   VG_(clo_wierd_hacks)      = NULL;
 
    eventually_logfile_fd = VG_(clo_logfile_fd);
 
@@ -797,6 +799,9 @@ static void process_cmd_line_options ( void )
       else if (STREQ(argv[i], "--trace-pthread=all"))
          VG_(clo_trace_pthread_level) = 2;
 
+      else if (STREQN(14, argv[i], "--wierd-hacks="))
+         VG_(clo_wierd_hacks) = &argv[i][14];
+
       else if (STREQN(13, argv[i], "--stop-after="))
          VG_(clo_stop_after) = VG_(atoll)(&argv[i][13]);
 

diff --git a/vg_mylibc.c b/vg_mylibc.c
index fec258af74b86c02d256b0a6fbda6e59d7fa10aa..f42ba9400b606679f7dfb696a26f9aae449739a4 100644 (file)
--- a/vg_mylibc.c
+++ b/vg_mylibc.c
@@ -740,7 +740,10 @@ Int VG_(strncmp_ws) ( const Char* s1, const Char* s2, Int nmax )
 
 Char* VG_(strstr) ( const Char* haystack, Char* needle )
 {
-   Int n = VG_(strlen)(needle);
+   Int n; 
+   if (haystack == NULL)
+      return NULL;
+   n = VG_(strlen)(needle);
    while (True) {
       if (haystack[0] == 0) 
          return NULL;

diff --git a/vg_scheduler.c b/vg_scheduler.c
index 79056e7edfe889f4099bdd2081876e0d4c3cf800..88cbe3e747c5c2fca3bb4d2ffd159952d147e54d 100644 (file)
--- a/vg_scheduler.c
+++ b/vg_scheduler.c
@@ -972,7 +972,15 @@ void poll_for_ready_fds ( void )
       vg_assert(is_valid_tid(tid));
       syscall_no = vg_waiting_fds[i].syscall_no;
       switch (syscall_no) {
-         case __NR_read: 
+         case __NR_read:
+            /* In order to catch timeout events on fds which are
+               readable and which have been ioctl(TCSETA)'d with a
+               VTIMEout, we appear to need to ask if the fd is
+               writable, for some reason.  Ask me not why.  Since this
+               is strange and potentially troublesome we only do it if
+               the user asks specially. */
+            if (VG_(strstr)(VG_(clo_wierd_hacks), "ioctl-VTIME") != NULL)
+               VKI_FD_SET(fd, &writefds);
             VKI_FD_SET(fd, &readfds); break;
          case __NR_write: 
             VKI_FD_SET(fd, &writefds); break;