Re: [PATCH] Allow MemPool late initialization

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Fri, 01 Jul 2011 14:47:56 -0600

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.

> 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?

Cheers,

Alex.
Received on Fri Jul 01 2011 - 20:49:19 MDT

This archive was generated by hypermail 2.2.0 : Mon Jul 04 2011 - 12:00:03 MDT