2010/9/7 Šplíchal Jiří <splic...@tovek.cz>: > Yes, me and Borek wanted to merge our branches so I pushed all my changes - > and forgot > not to push this one. I removed it again in my local repository but > unfortunately I am not able to push the change > to the original repository - I always got the message "fatal: The remote end > hung up unexpectedly". I don't know what > to do. > But I could pull your changes.
A firewall/proxy issue, maybe? What do you get, if you execute: ssh -v <your sf login>@clucene.git.sourceforge.net > But back to the additional decRef: > - I tried to investigate it further and the situation is the following: > If the SegmentReader gets closed via close() then decRef() method is called > where the Norms are also decRefed and the > close flag is being set - this happens in the close() method. > If you just delete a SegmentReader than the doClose() method is called and > the Norms are not touched - so memory leaks > arise. So I added the decRef() calls to the destructor, called only if the > closed false is false. > But when the SegmentReader is used as a child merger of MultiSegmentReader > and you call close() on the MultiSegmentReader, > then the child SegmentReaders are just decRefed (which leads to doClose() > call) but the closed flag remains false. > > I tried to find the right position for setting the closed flag to true (in > the doClose() method?) but I did not finish > the fix yet. The simplest solution is ofcourse not to forget to call the > close() method on the SegmentReader before > deleting it. Would be the best at the moment. Ben wrote once [1] that is a reason for the current behaviour. Another solution will be to use a smart/shared pointer here, so manually handling a reference counter isn't needed anymore. But this is a task I still have to complete. Veit [1] http://comments.gmane.org/gmane.comp.jakarta.lucene.clucene.devel/2505 ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ CLucene-developers mailing list CLucene-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/clucene-developers
