There have been multiple reports of cases where a real locked entry was
removed, resulting in a segmentation fault later in a worker which locked
the entry.  It looks like default inactive timeout isn't enough in real
life.

For now just ignore such locked entries, and move them to the top of the
inactive queue to allow processing of other entries.

There are two possible situations which can lead to this: response was
cached with bigger proxy_buffer_size value (and nginx was restared since
then, i.e. shared memory zone content was lost), or due to the race in
the cache update code (see [1]) we've end up with fcn->body_start from
a different response stored in shared memory zone.

[1] http://mailman.nginx.org/pipermail/nginx-devel/2011-September/001287.html

The ngx_http_cache() and ngx_http_no_cache_set_slot() functions were replaced
by ngx_http_test_predicates() and ngx_http_set_predicate_slot() in 0.8.46 and
no longer used since then.

the "proxy_redirect" directive.

haven't been sent to a client.

The ngx_http_variable_headers() and ngx_http_variable_unknown_header() functions
did not ignore response header entries with zero "hash" field.

Thanks to Yichun Zhang (agentzh).