Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,252
    • Issues 5,252
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 561
    • Merge requests 561
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #2703
Closed
Open
Issue created Oct 16, 2008 by sclv@trac-sclv

Buffer overflow, occasional segfaults when using handles created by Network.

See attached test cases (BigSock and BigSockFail). They both implement a simple echo server that reads lines from a socket and writes them to stdout -- the working case using the underlying Network.Socket API and the failing case using handles from the Network library.

If a single line of sufficient size (We used a 5MB file, but a smaller one would probably be fine) is sent to the working case, it behaves as expected, eventually writing out the line. Additional connections may be made during this, which write data to stdout as expected. Additional connections may also be made following this.

If a line of the same size is sent to the failing case, it occasionally segfaults, although this is hard to reproduce. When it does not segfault, the socket nonetheless becomes permanently nonresponsive. The large line is never output. Future connections are accepted by the binary (i.e. netcat reveals they are accepted), but the accept call in Haskell never succeeds, and no further interaction with the binary over the socket is possible.

This behavior has caused some massive grief before the cause was tracked down.

Both cases have been tested with the threaded runtime.

Trac metadata
Trac field Value
Version 6.8.3
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component libraries/network
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking