linuxdcpp-team team mailing list archive

[Steven Sheehy <steven.sheehy@xxxxxxxxx>]

Sorry, you're right it doesn't munmap twice, I was mistaken. However,
before rev 351 the fast hash loop had an extra, useless iteration in
which size_left == 0, pos == size and no memory is mmapped as a result
due to the if(size_left > 0) check. Your patch stops it from entering
that extra iteration similar to how rev 351 does. Our point is that
there was no memory being allocated during this last iteration so we're
not sure why you experience leaking. If you were to put a printf of the
buf address and size_read when it was mmap'd and munmap'd, you would see
that there was a munmap for every mmap even before rev 351.

The only thing that occurs on that extra iteration is a tth.update and a
crc calculation. So perhaps those were causing leaks for you. Does your
system happen to be big endian? Tiger hash behaves differently on big
endian.

-- 
Memory leak while hashing
https://bugs.launchpad.net/bugs/517948
You received this bug notification because you are a member of LinuxDC++
Team, which is subscribed to LinuxDC++.

Status in Linux DC++: Incomplete

Bug description:
Looks like memory mappings are destroyed on Linux when the file descriptor is closed. This is not the case on FreeBSD.

Please see attached patch.