httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 56977] New: segfaults when using mod_mem_cache + mod_disk_cache on a reverse proxy with mod_proxy + mod_proxy_http
Date Fri, 12 Sep 2014 16:52:31 GMT

            Bug ID: 56977
           Summary: segfaults when using mod_mem_cache + mod_disk_cache on
                    a reverse proxy with mod_proxy + mod_proxy_http
           Product: Apache httpd-2
           Version: 2.2.22
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: mod_mem_cache

Created attachment 32013
A test PHP file to help in reproducing the crash.

We have an application (Moodle 2.6) that switches from sending "Cache-Control:
public" to "Cache-Control: private" headers for the same content depending upon
whether or not the user is logged in.

That application is served via a reverse proxy using mod_proxy/mod_proxy_http
to backends running mod_php5/mod_xsendfile (among others).

Traditionally we've also allowed the use of mod_disk_cache on the reverse

Recently we also added mod_mem_cache *before* the mod_disk_cache confs so that
highly requested content could be served more rapidly from the in memory cache:
<IfModule mod_mem_cache.c>
CacheEnable mem /
<IfModule mod_disk_cache.c>
CacheEnable disk /

It was discovered that for that content that switches between public and
private Cache-Control headers, when the request is made for content that is in
the cache (originally via public Cache-Control headers), but has expired so
that a revalidation request is required, then the Apache process will segfault.

Based on the backtrace from the coredump, it appears that the segfault is while
mod_mem_cache is attempting to remove the now stale (since it now has
Cache-Control: private) entry from the cache.

If we remove mod_mem_cache from the mix, then this does not occurr. 
mod_disk_cache appropriately stores, serves, and then removes the cache entry
as necessary.

Attached are a test php script (proxycaching-index.php) and proxy coredump
backtrace output (reverse-proxy-backtrace).

It was also reported to me, though I could not reproduce this other error case,
that aside from segfaults, sometimes the mod_mem_cache configuration would just
return "garbage data".  My guess would be that it returned partial data or data
from an alternative Vary.

Also, I wasn't able to reliably reproduce this bug with content <
MCacheMaxObjectSize or without the "Accept-Ranges: bytes" header.  I suspect
that those aspects are also tied up in the issue.

So, to test this I did the following:
- setup a reverse proxy with mod_mem_cache and mod_disk_cache (in that order).
- place proxycaching-index.php in /proxycaching/ of a vhost.  Make sure
$private = 0 at the top of the file
- add "XSendFile On" in that backend vhost's .htacces (just a convinience for
sending the file)
- copy /usr/share/cups/data/default-testpage.pdf (or someother pdf) into
/proxycaching/default-testpage.pdf.  It may or may not be important that the
size of that file is > MCacheMaxObjectSize
- run the following a few times to prime the cache in each worker mpm process
with "public content":
# curl -v -s -o /tmp/curl.out http://vhostaddress/proxycaching/index.php; file
/tmp/curl.out; ls -l /tmp/curl.out
- switch $private = 1 in the /proxycaching/index.php file
# rerun the curl command a few times

Let me know if you need any more details.


You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message