apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 46588] New: apr_memcache_multgetp memory corruption and incorrect error handling
Date Thu, 22 Jan 2009 13:13:27 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=46588

           Summary: apr_memcache_multgetp memory corruption and incorrect
                    error handling
           Product: APR
           Version: 1.3.4
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: APR-util
        AssignedTo: bugs@apr.apache.org
        ReportedBy: sami.tolvanen@mywot.com


Created an attachment (id=23161)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23161)
Proposed fixes

The attached patch (against APR-util 1.3.4) includes proposed fixes to three
related problems in apr_memcache_multgetp.

1. When testing apr_memcache_multgetp under high loads, we noticed a bizarre
problem where epoll_wait in apr_pollset_poll randomly failed with EBADF. This
was traced back to subtle memory corruption in apr_memcache_multgetp caused by
the following sequence of actions:

  a. a pollset is created from temp_pool using apr_pollset_create
  b. temp_pool is cleared with apr_pool_clear
  c. apr_pollset_destroy is called for the now invalid pollset pointer

This doesn't result in a segfault, because the memory is still allocated in the
pool. However, it starts causing problems after a sufficient number of
iterations. The patch solves the problem simply by calling apr_pollset_destroy
before the temp_pool is cleared.

2. If apr_pollset_poll fails for any reason in apr_memcache_multgetp, the
function releases connections to the reslist without cleaning them up first. As
requests have already been sent to servers at this point, when the next user of
the connection reads from the socket, it receives the response to the previous
abandoned request instead. Since apr_pollset_poll failures should be rare, the
patch opts to solve the problem simply by invalidating the affected connections
in mget_conn_result in case of a failure (rv != APR_SUCCESS at the end of
apr_memcache_multgetp).

3. Similarly, if apr_pollset_create fails for any reason, apr_memcache_multgetp
returns immediately without releasing connections. The patch solves the problem
by calling mget_conn_result for each acquired connection if apr_pollset_create
fails.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


Mime
View raw message