Re: [PATCH] Allow MemPool late initialization

On 02/07/11 08:47, Alex Rousskov wrote:
> On 06/30/2011 06:13 AM, Amos Jeffries wrote:
>> The problem:
>>
>>> On 24/06/11 02:43, Kinkie wrote:
>>>> Hi all,
>>>>
>>>> 2011/06/23 16:38:39 kid3| assertion failed: mem.cc:516: "MemPools[t]"
>>>>
>>>> at startup
>>>>
>>
>> FQDN had memDataInit() in its component setup, which moved. The assert
>> is in memCheckInit() and tests that memInit() worked properly. But if a
>> pool is initialized only when its component is loaded, that check will
>> fail on several conditions unrelated to the operation of memory.
>> Seemingly trivial changes to component loading order is one case.
>>
>> This patch allows modules to initialize/register their own pools on
>> demand later in the startup process.
>>
>> * shuffle MEM_DONTFREE which is an existing fixed entry that must not be
>> memInitCheck()'d to the end of the MemPool type enum list.
>>
>> * update memCheckInit() to stop scanning for missing pools at that marker.
>>
>> * shuffle pool types which are initialized by their components after the
>> marker value. Such that no false problem is reported if (a) the
>> component is never initialized for that worker, or (b) the component is
>> only initialized during the configuration process.
>>
>> * document this layout significance in the enum list to aid future pool
>> additions or moves.
>>
>> * add asserts to memAllocate() and memFree() to highlight the cases of
>> brokenness memCheckInit() was catching. Using assert() instead of if()
>> so that optimized builds can avoid the penalty of an extra test on each
>> alloc/free.
>
>> + ++t;
>> +
>> + do {
> ...
>> - }
>> + } while(++t< MEM_DONTFREE);
>
>
> I think the above can be shortened/clarified as
>
> while (++t< MEM_DONTFREE) { ... }
>
> or even go back to the old for-loop that was there, but stop it at
> MEM_DONTFREE.
>

Thank you. Seems to work.
Amended patch attached.

>
>> NP: so far this patch gets me past the assert Kinkie hit (and two others
>> similar). Then dies in Strand.cc (2 workers, minimal config) with a
>> Segmentation fault that should not exist and cannot be replicated using -N.
>
> Do you get the same segmentation fault if you undo your patch but
> disable memCheckInit() so that the latter is not in the way?

Yes, simple #if 0...#endif around the content of memCheckInit() leads
to the same SegFault in 3.2. Opened bug 3264 about this.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.14
   Beta testers wanted for 3.2.0.9