You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by tr...@apache.org on 2009/11/14 03:27:21 UTC

svn commit: r836098 - /apr/apr/branches/1.4.x/poll/unix/port.c

Author: trawick
Date: Sat Nov 14 02:27:21 2009
New Revision: 836098

URL: http://svn.apache.org/viewvc?rev=836098&view=rev
Log:
merge r836091 from trunk:

Check that an event was actually filled in when
port_getn() returns -1/EINTR with nget > 0.

This resolves a crash when receiving a signal.

PR: 48030

Modified:
    apr/apr/branches/1.4.x/poll/unix/port.c

Modified: apr/apr/branches/1.4.x/poll/unix/port.c
URL: http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/poll/unix/port.c?rev=836098&r1=836097&r2=836098&view=diff
==============================================================================
--- apr/apr/branches/1.4.x/poll/unix/port.c (original)
+++ apr/apr/branches/1.4.x/poll/unix/port.c Sat Nov 14 02:27:21 2009
@@ -103,6 +103,10 @@
         tvptr = &tv;
     }
 
+    list[0].portev_user = (void *)-1; /* so we can double check that an
+                                       * event was returned
+                                       */
+
     ret = port_getn(port, list, max, nget, tvptr);
     /* Note: 32-bit port_getn() on Solaris 10 x86 returns large negative 
      * values instead of 0 when returning immediately.
@@ -114,10 +118,12 @@
         switch(rv) {
         case EINTR:
         case ETIME:
-            if (*nget > 0) {
+            if (*nget > 0 && list[0].portev_user != (void *)-1) {
                 /* This confusing API can return an event at the same time
                  * that it reports EINTR or ETIME.  If that occurs, just
-                 * report the event.
+                 * report the event.  With EINTR, nget can be > 0 without
+                 * any event, so check that portev_user was filled in.
+                 *
                  * (Maybe it will be simplified; see thread
                  *   http://mail.opensolaris.org
                  *   /pipermail/networking-discuss/2009-August/011979.html