summaryrefslogtreecommitdiff
path: root/Crypto.hs
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2011-04-19 15:26:50 -0400
committerGravatar Joey Hess <joey@kitenet.net>2011-04-19 15:27:03 -0400
commit5985acdfad8a6791f0b2fc54a1e116cee9c12479 (patch)
tree79bb1aa8ff55e4c53dc5ca08ea511aa6f9bd4232 /Crypto.hs
parentb1274b637863ebb4e14d39ca2cf00a27c9d1f142 (diff)
bup: Avoid memory leak when transferring encrypted data.
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.
Diffstat (limited to 'Crypto.hs')
-rw-r--r--Crypto.hs20
1 files changed, 10 insertions, 10 deletions
diff --git a/Crypto.hs b/Crypto.hs
index 41f6b999b..478d83761 100644
--- a/Crypto.hs
+++ b/Crypto.hs
@@ -153,24 +153,24 @@ encryptKey c k =
{- Runs an action, passing it a handle from which it can
- stream encrypted content. -}
-withEncryptedHandle :: Cipher -> L.ByteString -> (Handle -> IO a) -> IO a
+withEncryptedHandle :: Cipher -> (IO L.ByteString) -> (Handle -> IO a) -> IO a
withEncryptedHandle = gpgCipherHandle [Params "--symmetric --force-mdc"]
{- Runs an action, passing it a handle from which it can
- stream decrypted content. -}
-withDecryptedHandle :: Cipher -> L.ByteString -> (Handle -> IO a) -> IO a
+withDecryptedHandle :: Cipher -> (IO L.ByteString) -> (Handle -> IO a) -> IO a
withDecryptedHandle = gpgCipherHandle [Param "--decrypt"]
{- Streams encrypted content to an action. -}
-withEncryptedContent :: Cipher -> L.ByteString -> (L.ByteString -> IO a) -> IO a
+withEncryptedContent :: Cipher -> (IO L.ByteString) -> (L.ByteString -> IO a) -> IO a
withEncryptedContent = pass withEncryptedHandle
{- Streams decrypted content to an action. -}
-withDecryptedContent :: Cipher -> L.ByteString -> (L.ByteString -> IO a) -> IO a
+withDecryptedContent :: Cipher -> (IO L.ByteString) -> (L.ByteString -> IO a) -> IO a
withDecryptedContent = pass withDecryptedHandle
-pass :: (Cipher -> L.ByteString -> (Handle -> IO a) -> IO a)
- -> Cipher -> L.ByteString -> (L.ByteString -> IO a) -> IO a
+pass :: (Cipher -> (IO L.ByteString) -> (Handle -> IO a) -> IO a)
+ -> Cipher -> (IO L.ByteString) -> (L.ByteString -> IO a) -> IO a
pass to c i a = to c i $ \h -> a =<< L.hGetContents h
gpgParams :: [CommandParam] -> IO [String]
@@ -203,8 +203,8 @@ gpgPipeStrict params input = do
-
- Note that to avoid deadlock with the cleanup stage,
- the action must fully consume gpg's input before returning. -}
-gpgCipherHandle :: [CommandParam] -> Cipher -> L.ByteString -> (Handle -> IO a) -> IO a
-gpgCipherHandle params c input a = do
+gpgCipherHandle :: [CommandParam] -> Cipher -> (IO L.ByteString) -> (Handle -> IO a) -> IO a
+gpgCipherHandle params c a b = do
-- pipe the passphrase into gpg on a fd
(frompipe, topipe) <- createPipe
_ <- forkIO $ do
@@ -217,11 +217,11 @@ gpgCipherHandle params c input a = do
params' <- gpgParams $ passphrase ++ params
(pid, fromh, toh) <- hPipeBoth "gpg" params'
_ <- forkProcess $ do
- L.hPut toh input
+ L.hPut toh =<< a
hClose toh
exitSuccess
hClose toh
- ret <- a fromh
+ ret <- b fromh
-- cleanup
forceSuccess pid