Skip to content
Snippets Groups Projects
  1. Apr 21, 2011
  2. Apr 20, 2011
  3. Apr 19, 2011
    • Joey Hess's avatar
      heard from hS3 author · 936ad63c
      Joey Hess authored
      936ad63c
    • Joey Hess's avatar
      2b742dcd
    • Joey Hess's avatar
      update on memory leak · 48371768
      Joey Hess authored
      Finished applying to S3 the change that fixed the memory leak in bup, but
      it didn't seem to help S3.. with encryption it still grows to 2x file size.
      48371768
    • Joey Hess's avatar
      Added a comment · ef6d265a
      Joey Hess authored
      ef6d265a
    • Joey Hess's avatar
      update · 030c7a05
      Joey Hess authored
      030c7a05
    • Joey Hess's avatar
      bup: Avoid memory leak when transferring encrypted data. · 5985acdf
      Joey Hess authored
      This was a most surprising leak. It occurred in the process that is forked
      off to feed data to gpg. That process was passed a lazy ByteString of
      input, and ghc seemed to not GC the ByteString as it was lazily read
      and consumed, so memory slowly leaked as the file was read and passed
      through gpg to bup.
      
      To fix it, I simply changed the feeder to take an IO action that returns
      the lazy bytestring, and fed the result directly to hPut.
      
      AFAICS, this should change nothing WRT buffering. But somehow it makes
      ghc's GC do the right thing. Probably I triggered some weakness in ghc's
      GC (version 6.12.1).
      
      (Note that S3 still has this leak, and others too. Fixing it will involve
      another dance with the type system.)
      
      Update: One theory I have is that this has something to do with
      the forking of the feeder process. Perhaps, when the ByteString
      is produced before the fork, ghc decides it need to hold a pointer
      to the start of it, for some reason -- maybe it doesn't realize that
      it is only used in the forked process.
      5985acdf
    • Joey Hess's avatar
      refactor · b1274b63
      Joey Hess authored
      b1274b63
    • Joey Hess's avatar
      Fix stalls in S3 when transferring encrypted data. · a441e08d
      Joey Hess authored
      Stalls were caused by code that did approximatly:
      
      content' <- liftIO $ withEncryptedContent cipher content return
      store content'
      
      The return evaluated without actually reading content from S3,
      and so the cleanup code began waiting on gpg to exit before
      gpg could send all its data.
      
      Fixing it involved moving the `store` type action into the IO monad:
      
      liftIO $ withEncryptedContent cipher content store
      
      Which was a bit of a pain to do, thank you type system, but
      avoids the problem as now the whole content is consumed, and
      stored, before cleanup.
      a441e08d
    • Joey Hess's avatar
      bug · 1687fecd
      Joey Hess authored
      1687fecd
    • Joey Hess's avatar
      4cbd71b0
  4. Apr 17, 2011