Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,262
    • Issues 4,262
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 404
    • Merge Requests 404
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #3128

Closed
Open
Opened Mar 28, 2009 by Baughn@trac-Baughn

hClose leaves file descriptor open if it fails

In libraries/base/GHC/Handle.hs, function hClose_help, we attempt to flush the write buffer before closing a handle's underlying FD.

If flushing the write buffer fails, for example if this is a network socket that has been closed by the remote host, hClose throws an exception inside flushWriteBufferOnly and the socket is not closed. As a result, the program leaks sockets.

The solution is to always close the FD (that is, call hClose_handle_) regardless of errors, but I am not confident of writing correct exception-handling code without the usual abstractions available.

Also, inside hClose_handle_, an error is thrown if c_close ever returns -1. It may be practically impossible for this to be caused by EINTR, but is it theoretically impossible?

Trac metadata
Trac field Value
Version 6.10.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component libraries/base
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Assignee
Assign to
6.12.1
Milestone
6.12.1
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#3128