<div dir="ltr">Hi Maxim,<div> I understand on array overflow nginx creates a new memory block. That is perfectly alright.</div><div><br></div><div>Say I have a Pool and array is allocated from the first memory block and it happend such a way that array elements end at pool->d.last.</div>
<div> </div><div>Now, say the pool is used for some other purposes such a way that pool->current is now pointing to a different memory block say '2'</div><p class="">And if we want to allocate a few more array elements, nginx has to use second memory block. Now the elements are moved to second memory block.</p>
<p class="">At this stage, if any new element is requested that results in overflow, nginx does the below checks</p><p class=""> <span class="">if</span> ((u_char *) a->elts + size == p->d.last</p><p class="">
&& p->d.last + a->size <= p->d.end)</p><p class="">
</p><p class="">In the above code, p->d.last was actually pointing to the end of first memory block but not second memory block. Hence <b>even though there is memory available in second memory block</b> it will go ahead and create a new memory block. This will repeat on each overflow. </p>
<p class=""><br></p><p class="">And, the code in ngx_array_destroy() will actually set the pointer(p->d.last) wrongly once there is a overflow. This is a critical issue.</p><div>First memory block would have say 'n' elements but after overflow number of elements become 2 times of n.</div>
<div>Lets say after second overflow, I destroyed the array, then p->d.last will be set backwards by 2 times in the first memory block. But, in actuality it was size 'n'.</div><div><br></div><div>Nginx never faces that situation because, once a memory block is set to 'failed', it wont be used for allocation any more. But, if the 'failed' count is less than 4 then we may have issue and also pool destroy may have potential issues.</div>
<div><br></div><div>Sorry for long email, but I wanted to explain that in detail.</div><div><br></div><div>Thanks,</div><div>-Ravi.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 16, 2014 at 6:40 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<div><div class="h5"><br>
On Thu, Jan 16, 2014 at 06:22:58PM -0800, Ravi Chunduru wrote:<br>
<br>
> Hi Nginx experts,<br>
> Thanks for the prompt reply to my earlier email on ngx_reset_pool()<br>
><br>
> Now, I am looking into ngx_array.c. I found an issue ngx_array_push(). Here<br>
> are the details.<br>
> nginx will check if number of elements is equal to capacity of the array.<br>
> If there is no space in the memory block, it allocates a new memory block<br>
> with twice the size of array and copies over the elements. So far so good.<br>
> Assume that pool utility got entirely new memory block then a->pool is not<br>
> updated with that of 'pool->current'.<br>
><br>
> I got an assumption from the code that a->pool is always the memory block<br>
> that has the array elements by seeing the code in ngx_array_push(),<br>
> ngx_array_push_n() or ngx_array_destroy() where checks were always done<br>
> with pool pointer in array.<br>
><br>
> Functionalities issues would come up once there is an array overflow. I<br>
> think for every new push of element after first crossing/overflow of the<br>
> capacity, nginx will keep on creating new array. Thus it results in wastage<br>
> of memory.<br>
><br>
> Please let me know if its a issue or correct my understanding.<br>
<br>
</div></div>That's expected behaviour. Arrays are implemented in a way that<br>
allocates additional memory on overflows, and it's expected to<br>
happen. There is a ngx_list_t structure to be used if such<br>
additional memory allocations are undesired. Optimization of<br>
allocations which uses pool internals is just an optimization and<br>
it's not expected to always succeed.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" target="_blank">http://nginx.org/</a><br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ravi<br>
</div>