Fix assert in StoreEntry::write() when aborted entry is written.

HttpStateData::processReply() calls adaptOrFinalizeReply(), which
calls ServerStateData::setFinalReply(), which calls
entry->startWriting(), which calls StoreEntry::invokeHandlers() which
calls client-side code, which may abort or otherwise "close" the
entry.

After adaptOrFinalizeReply() returns to HttpStateData::processReply(),
HttpStateData::processReply() calls HttpStateData::processReplyBody(),
which may try to write to the aborted/closed entry, leading to
asserts.

At least the following scenario triggers the bug:

* client send a regular GET for a cached stale object
* Squid sends an IMS verification request to the origin server
* the origin server replies with 304 (Not Modified)

In this case adaptOrFinalizeReply() in HttpStateData::processReply()
would abort the origin server reply entry, leading to assert.

The patch adds a checks that entry still can accept more data after
the adaptOrFinalizeReply() call.

diff --git a/src/http.cc b/src/http.cc
index 17bbbc30037f902cb1c8d76abee0dd1310781b7f..01b163baff8384b4028d41eca1d7163b7f1ebad4 100644 (file)
--- a/src/http.cc
+++ b/src/http.cc
@@ -1209,6 +1209,9 @@ HttpStateData::processReply()
             return; // TODO: send errors to ICAP
 
         adaptOrFinalizeReply();
+        // adaptOrFinalizeReply() may abort or otherwise "close" the entry
+        if (!entry->isAccepting())
+            return;
     }
 
     // kick more reads if needed and/or process the response body, if any