[squid-users] Squid SMP workers crash

[Deniz Eren]

On 10/18/16, Alex Rousskov <rousskov at measurement-factory.com> wrote:
> On 10/17/2016 10:37 PM, Deniz Eren wrote:
>> On Mon, Oct 17, 2016 at 7:43 PM, Alex Rousskov wrote:
>>> On 10/17/2016 02:38 AM, Deniz Eren wrote:
>>>> 2016/10/17 11:22:37 kid1| assertion failed:
>>>> ../../src/ipc/AtomicWord.h:71: "Enabled()"
>>>
>>> Either your Squid does not support SMP (a build environment problem) or
>>> Squid is trying to use SMP features when SMP is not enabled (a Squid
>>> bug).
>>>
>>> What does the following command show?
>>>
>>>   fgrep -RI HAVE_ATOMIC_OPS config.status include/autoconf.h
>> fgrep -RI HAVE_ATOMIC_OPS config.status include/autoconf.h
>> config.status:D["HAVE_ATOMIC_OPS"]=" 0"
>> include/autoconf.h:#define HAVE_ATOMIC_OPS 0
>
> Your Squid does not support SMP. The ./configure script failed to find
> the necessary APIs for SMP support. I wish Squid would tell you that in
> a less obscure way than an Enabled() assertion; feel free to file a bug
> report about that, but that is a reporting/UI problem; the assertion
> itself is correct.
Yes, you are right. Inspecting more carefully I saw that "Atomic"
support is missing.

>
> I do not know why your build environment lacks atomics support (or why
> Squid cannot detect that support), but I hope that others on the mailing
> list would be able to help you with that investigation.
Fixing system include paths solved the problem. Thanks for pointing me
what the problem is.

>
>
> Finally, in the interest of full disclosure, I have to note that, IIRC,
> atomics are not actually required for some of the primitive SMP
> features, but Squid attempts to create a few shared memory tables even
> when those tables are not needed, and those tables do require atomics
> (and will hit the Enabled() assertion you have reported).
>
> There have been improvements in this area; eventually no unnecessary
> shared memory tables will be created, but it is probably easier for you
> to get a build with working atomics (usually does not require any
> development) than to get rid of those tables (which probably require
> more development).
>
> Alex.
>
>