Search squid archive

Re: squid 5.3 frequent crash

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux