[Date Prev][Date Next]
RE: back-bdb resource leak (ITS#2040)
The SleepyCat support request ID is #6520.
I did some more testing to try to find the relevant size limits. I created an
objectclass slot with 65332 entries. (A bit shy of the 65535 limit, but close
enough for this test.) With a 1MB buffer we get all 65332 entries in one
shot. I then tried a 512K buffer, assuming it would take two reads. Instead,
I got 32729 in the first read, 32602 in the next read, and 1 in the 3rd read.
With the trailing get() to make sure we got everything, this leaked 3 lockers
per search attempt. I also tried a 768K buffer, which read 49005 entries in
the first attempt, the remainder in the second attempt, and leaked 1 locker
on the last get() that returns DB_NOTFOUND. Since the number of items
returned doesn't appear to be linear with the buffer size, I committed a fix
that uses 1.25MB for the buffer, which should be able to hold the 65535 items
plus any additional overhead.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support