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.
