On 6/4/20 4:15 PM, senor wrote: > I occasionally get an assert and core dump on a worker here: > #3 in ClientHttpRequest::resetRequest () at client_side_request.cc:1676 I assume you are hitting assert(request != newRequest). > #4 in ClientHttpRequest::handleAdaptedHeader () at client_side_request.cc:2005 > As I understand it, the request returned from adaptation is compared > with pre-adapted request and it is considered a fail if they match. > Since there is no requirement that adaptation make a change, I assume > it should not be in that code unless adaptation indicated there was a > change. IIRC, Squid ICAP client code creates a new request structure even if no adaptation happened at the ICAP service. This is a deficiency of that old code (some may say a bug, but there could have been good reasons to make it that way back then because that request structure is "special" and may have been difficult to reuse -- I am not sure). Apparently, there is some other adaptation code that does not create a new request structure. I speculate that it may be the request routing code that lives outside the ICAP space (it also serves eCAP adapters). For a specific example, see Adaptation::Iterator::step() -- I see no obvious/immediate signs there that theMsg is a new message and not the virgin one. IIRC, theMsg starts as a virgin message structure. I suspect that the correct fix would be to stop requiring a new request structure for the akForward Answers. Instead, handleAdaptedHeader() should accommodate the case where the request structure was preserved and does not need to be reset. In other words, a Forward(x) answer should not imply that the original message was (not) adapted. Other Answer recipients should be checked for a similar problem. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
