They are NOT the same, since what you proposed would have caused more
memory leaks (from the head of the array, which contains actual objects).
I have discussed what needs to be done further in my previous mail
(further testing & killing memleaks).
Itamar.
On 29/6/2010 10:21 AM, Kostka Bořivoj wrote:
> This is the same solution (except you use much more efficient way) I proposed
> in one of my previous mails:
>
>
>> To test this, I simply added (yes it might be done more efficient way using
>> memset)
>>
>> for ( size_t i = this->postingsFreeCountDW; i<
>> this->postingsFreeListDW.length; i++ ){
>> this->postingsFreeListDW.values[i] = NULL; }
>>
> and you told me this will introduce memory leaks. And there are some in
> cl_demo.
>
> So you think this is OK, or some additional exploration should be done?
>
> Borek
>
>
>> -----Original Message-----
>> From: Itamar Syn-Hershko [mailto:[email protected]]
>> Sent: Tuesday, June 29, 2010 12:35 AM
>> To: [email protected]
>> Subject: Re: [CLucene-dev] vector subscript outofrangeexceptionduringindexing
>>
>> Alrighty, seems like I have nailed it. See below + attached patch.
>>
>> On 29/6/2010 12:39 AM, Kostka Bořivoj wrote:
>>
>>> I'm quite sure the problem is in postingsFreeListDW management:
>>>
>>> The postings after postingsFreeCountDW are used somewhere (but are
>>> still here in a list). If you remove block of free postings in
>>> balanceRAM, you are removing before postingsFreeCountDW so an "empty
>>> block" is created inside postingsFreeListDW (at the end of free
>>> postings but before all used postings). Then if you return all/some used
>>> postings
>>>
>> back into list, you return them to the beginning of this empty block. This
>> can cause
>> duplicated pointers in the list.
>>
>>>
>> I agree there is an empty block, I am just not sure how this could cause
>> duplicated
>> pointers?
>>
>> Also, claiming the culprit is postingsFreeListDW's memory management is less
>> likely
>> since it most likely would have been noticed by Java users / devs already.
>>
>>
>>> It can also be a reason, why postingsFreeCountDW<
>>> postingsFreeListDW.length in
>>>
>> the destructor.
>>
>>>
>> I am not at all sure this is an actual problem. postingsFreeListDW can have
>> more
>> allocated memory than needed (hence< length).
>>
>>> Borek
>>>
>> Anyway, I put a breakpoint on Array.h ln 139 and noticed it errored on
>> array item 5888 (0-base). This was also the value of
>> postingsFreeCountDW. What this means is the "gap" you were referring to
>> is actually in the tails of the postings array. Some code moving
>> postings around didn't bother at NULLifying unused positions.
>>
>> Instead of looking up this erroneous code, I added a memset call to
>> NULLify the tail of that array at the end of the destructor. It also
>> makes more sense performance-wise, and as long as no memory leaks are
>> introduced, I think it is safe to keep it that way.
>>
>> So, what we need now is to make sure this doesn't introduce new leaks,
>> and have this properly tested before checking this change in (all
>> cl_tests pass atm). I know cl_demo leaks but haven't had the time to see
>> where from - this could be related. Can you handle that?
>>
>> Itamar.
>>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> CLucene-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/clucene-developers
>
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
CLucene-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clucene-developers
