If someone has aknowledged this problem, please reply, I'm getting the feeling nobody want's to do anything about it...
I've been away for a few days, and I'm now catching up. Sorry for the delay.
Brief description: if the remote side of a socket closes the connection, any write will cause a sigPIPE signal, if a signal handler ignoring the signal is in place this results in an IO exception in the write call (or flush). At this point the local end of the socket still exists and needs to be closed by a call to c_close, howerver, hClose and the finalizer both try to flush the write side causeing a second exception, resulting in the handle never getting closed, and leaking...
Here is a potential solution: (maybe better to use catchJust ioErrors)
handleFinalizer :: MVar Handle__ -> IO () handleFinalizer m = do h_ <- takeMVar m catch (flushWriteBufferOnly h_) (\e -> return()) -- catch exception if remote side closed let fd = fromIntegral (haFD h_) unlockFile fd when (fd /= -1) #ifdef mingw32_TARGET_OS (closeFd (haIsStream h_) fd >> return ()) #else (c_close fd >> return ()) #endif return ()
Yes, that's a good bug. The buffer flushing operations are interruptible, so we should guard against asynchronous exceptions being delivered at those points. Cheers, Simon