[squid-users] FATAL: assertion failed: mem/PageStack.cc:159: "StoredNode().is_lock_free()"

[Alex Rousskov]

On 2024-07-04 04:57, Nishant Sharma wrote:
> On 03/07/24 21:27, Alex Rousskov wrote:
>> On 2024-07-03 09:27, Nishant Sharma wrote:
>>> Is there any change that we need to do in the configure script to 
>>> check for the availability of 64 bit atomic lock and use 32 bit lock 
>>> if not available?

>> It is technically possible (perhaps even without ./configure checks), 
>> but it would require adjusting complex shared tree code in the abcense 
>> of comprehensive ready-to-use tests. It is trivial to break that code. 
>> It is difficult to detect bugs. IMO, we should not expose ourselves to 
>> such risks in this case, especially since Squid uses 64-bit atomics in 
>> many other places: Supporting 32 bits in shared binary tree nodes is 
>> not going to remove the last frequently used 64-bit lock.

> Just being curious here, if a certain platform (mips32 in this case) is 
> unable to guarantee a 64 bit atomic lock, other functions except SMP 
> mode might get affected as well?

The answer depends on where one draws "SMP mode" boundaries: The locks 
in question should have no effect on non-SMP Squid (i.e. Squids with 
only one worker process, no cache_dir diskers, and memory_cache_shared 
not turned on). Beyond that, it is very difficult to isolate "other 
functions" from "SMP mode" because a lot of Squid "functions" ought to 
be (and are becoming) SMP-aware and, hence, use shared memory locking.

>> Disclaimer: I do not know what "lock ID" is in this context.

> "lock ID" term was used on Openwrt issue tracker where it was suggested 
> that "The assertion assumes 64bit lock id.". [1]

Yes, I am aware. I wrote the disclaimer _after_ reading that thread :-).


> Let me experiment with squid-6.x on these devices and also use them in 
> the live environment.
> 
> The only change being commenting out the following line from 
> ipc/mem/PageStack.c:
> 
> `assertion(StoredNode().is_lock_free());`
> 
> I will report back with success or any failures encountered.


Thank you,

Alex.


> [1] 
> "https://github.com/openwrt/packages/issues/24469#issuecomment-2202322703"