[squid-users] Squid crash - 3.5.21

[Alex Rousskov]

Context: hindsight1 was replying to a 2016 email archived at
http://lists.squid-cache.org/pipermail/squid-users/2016-October/012881.html


On 11/10/19 7:13 AM, hindsight1 wrote:
> When running Squid4.8 on the arm using SMP. And setting 4 or 7,9  worker
> ,the same error occurred in the log.

>>> Received Bus Error...dying, 

> Debugging the core file with gdb found that the address was not aligned. 
> 
> Does it consider the case where only address-aligned access is supported on
> arm

I am not sure whether "it" in your sentence refers to gdb or Squid, but
if Squid dereferences an unaligned data field in shared memory, then it
is most likely a Squid bug.


> The question is, why is the type of Item in the PageStack class using
> uint32_t,

Probably to avoid wasting space: Squid Store does not yet support caches
with more than 16777215 entries (a signed 25-bit integer) and SMP-aware
caches do not support storing responses with more pages than that limit.
Even though response size and the number of responses are conceptually
different limits, the underlying code/structures tie the two together IIRC.


> can it be replaced with uint64_t or size_t?

I have not checked whether any other adjustments would be required, but
I suspect that the answer is "yes". Needless to say, this replacement
will waste RAM.


> When I change to uint64_t, the problem disappears.

If there is an unaligned access bug, we should fix that bug directly
rather than relying on side effects of field sizes or, at least, we
should confirm and document that those side effects are the right fix.

To fix this properly, a stack trace would be very helpful. Can you post
that?


Alex.


> Alex Rousskov wrote
>> On 10/03/2016 04:50 AM, Jasper Van Der Westhuizen wrote:
>>> This morning I had some problems with some of our proxies. 2 Proxies in
>>> cluster A crashed with the below errors. The shortly afterwards 4 in
>>> cluster B did the same. Both clusters are configured to run their cache
>>> in memory with SMP and 4 workers configured.
>>>
>>> FATAL: Received Bus Error...dying.
>>
>>
>> There are at least two possible reasons:
>>
>>   1. A bug in Squid and
>>   2. Memory overallocation by the OS kernel.
>>
>> To fix the former, the developers will need a stack trace (at least). I
>> recommend filing a bug report after getting that trace and excluding
>> reason #2. Squid wiki and various system administration guides explain
>> how to make Squid dump core files.
>>
>> To check for memory overallocation, you can temporary start Squid v4.0
>> with "shared_memory_locking on". Unfortunately, that squid.conf
>> directive is not available in Squid v3. You may be able to emulate it
>> using some OS-specific sysctl or environment variables, but doing so may
>> be far from trivial, and I do not have instructions.
>>
>>
>> HTH,
>>
>> Alex.