Pierangelo Masarati wrote: > [EMAIL PROTECTED] wrote: >> [EMAIL PROTECTED] wrote: >>> Full_Name: Pierangelo Masarati >>> Version: >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (81.72.89.40) >>> Submitted by: ando >>> >>> >>> After heavily loading a MMR pool, valgrind finds the following: >>> >>> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are >>> definitely >>> lo >>> st in loss record 13 of 15 >> Most likely because we increment s_inuse at line 1250, at the beginning of a >> non-Delete write op, and don't decrement it at the end of the op. I think >> this >> should be simple to fix, will take a look. > > Seems to work. Thanks, p.
I don't think the current fix is complete. Due to the Abandon check at 1190, it's possible (though extremely unlikely) for an Abandon to arrive between the start and end of a mod op, and cause the final decrement to be skipped still. Probably need to do some restructuring to catch this, I'll look at this some more. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
