From 7df2be1716f4faeba5138287e1596d2395c777bb Mon Sep 17 00:00:00 2001 From: Steve Slaven Date: Mon, 2 Nov 2009 22:13:08 -0800 Subject: Added note about mem leak with a bandaid fix diff --git a/FuseArchive/ChunkFile.py b/FuseArchive/ChunkFile.py index 99f7d32..c33ae73 100644 --- a/FuseArchive/ChunkFile.py +++ b/FuseArchive/ChunkFile.py @@ -363,23 +363,14 @@ class ChunkFile(object): logging.debug( "Pre-Buf: %s" % hexlify(buf) ) logging.debug( "Pre-Chunk: %s" % hexlify(self.chunk) ) - # Check if we are appending only, appends are much faster than - # splicing up string + # Check if we are appending only if self.chunk.length() == rest and len( buf ) <= this_len: logging.debug( "Doing quick append" ) self.chunk.append( buf ) else: - logging.debug( "SLOOOOW! Doing string splice" ) - # Since python doesn't do in-place reassignment like you - # can with splice() we will reconstruct the data by joining - # stuff by offsets (first chars to skip, then our joining - # buf chunk, the everything that would have been after it) - - # This sucks for moving around data, it is very slow! self.chunk.replace( buf[ buf_offset:(buf_offset+this_len) ], rest, rest + this_len ) - if FuseArchive.deep_debug: logging.debug( "Post-Buf: %s" % hexlify(buf) ) logging.debug( "Post-Chunk: %s" % hexlify(self.chunk) ) @@ -414,6 +405,13 @@ class ChunkFile(object): self.flush() self.file.close() + # There is some kind of mem leak, ChunkFile objects end up in a + # tuple of [obj,True] for every object written and never get freed, + # maybe a fuse bug? + del self.chunks + del self.chunk + del self.original_chunks + def _fflush(self): if self.wr and self.modified: logging.debug( "_fflush!" ) -- cgit v0.10.2