[squid-users] squid 5.3 frequent crash

[Amos Jeffries]

On 8/01/22 05:02, Alex Rousskov wrote:
> On 1/7/22 9:34 AM, Amos Jeffries wrote:
>> On 7/01/22 06:00, Alex Rousskov wrote:
>>> On 1/6/22 6:53 AM, Majed Zouhairy wrote:
>>>> after upgrading today to 5.3 i'm getting:
>>>
>>>> 2022/01/06 14:27:18 kid1| FATAL: check failed: opening()
>>>>       exception location: FwdState.cc(628) noteDestinationsEnd
>>>
>>>> what is the cause?
>>>
>>> This is most likely bug 5055 fixed in August 2021:
>>> https://bugs.squid-cache.org/show_bug.cgi?id=5055
>>>
>>> In many environments, Squid v5 is unusable without that bug fix. I do
>>> not know whether the v5 maintainer plans to officially backport the fix
>>> from master/v6 to v5, but we would be happy to assist with that.
> 
> 
>> The commit message documents that the bug fix is a small part of the
>> changes made.
> 
> I am unable to separate many of the bug fixes from most other changes in
> that commit. I am a fan of surgical fixes, but, sometimes, significant
> code changes are required to address a set of bugs. One could, of
> course, ignore most of the bugs fixed by the official commit and just
> make sure that v5 does not violate the opening() MUST that triggered
> this thread, but I see no point in doing that -- we will end up chasing
> one known bug after another, sometimes in circles, and often via painful
> triage.
> 
> 
>> Others include altering the fundamental AsyncJob API behaviour -
>> affecting every feature in Squid at their most fundamental levels.
> 
> I disagree with the above summary.
> 

This is not an opinion. The patch "part 2" makes logic changes to 
AsyncJob - specifically destructors and swanSong. That touches 
*everything* Squid does. The other parts touch I/O in similarly deep 
ways and we have a history of unexpected weird side effects with I/O 
refactorings.


> 
>> That amount of change is not going into a "stable" release of
>> Squid.
> 
> FWIW, IMHO, Squid v5 is much better with those changes than it is
> without them. Once tested, the changes do not violate any fundamental
> stability principles that I know of. However, I think it is best to let
> the maintainer (i.e. you) make v5 admission decisions. I am just
> providing feedback to facilitate informed decisions.


I do not disagree with the improvement existing. Just that it does not 
fit the criteria for backport into a stable/production release.

I am seriously considering using our exceptional beta release process 
for these changes once v5.4 bug fixes are out.


> 
>> I will consider patches for just the bug 5055 issue though.
> 
> To avoid misunderstanding, (the backport of) the official set of fixes
> is what I am offering for your consideration. If others can address all
> those bugs using smaller patches, great! Otherwise, I recommend
> backporting the comprehensive fix and am happy to assist with that.
> 

I will take you up on this.

FYI; I am clearing the backports queue over the next few days, and again 
just before 1st Feb. With stable v5.4 release scheduled for 6th Feb.

IMO the best code to base your backport PR on would be the v5 HEAD after 
1st Feb when I post the "prep for 5.4" or similar QA for review. With 
intention of a v5.4.1 beta release a few days later on 10th-12th 
containing only the big change.

That gives us 6 weeks for validation before v5.5 release decisions are 
made. I seriously *hope* that is enough testing not to be hit later with 
another one of these.


Amos