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,395
    • Issues 5,395
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 591
    • Merge requests 591
  • 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
  • #188
Closed
Open
Issue created Oct 07, 2003 by nobody@trac-nobody

seg faults with STArray

While trying to eliminate a space leak in a program
with lots of array updates, I switched the update
function to a (thaw to STArray, do the update, freeze).
This gave an order of magnitude improvement over
standard Haskell arrays (but not enough yet). However,
with big arrays I get segmentation faults with
unsafeThaw. This happens with ghc 5.04.1 and 6.0.1.
Attached is a small example program to illustrate the
problem.

For small problem sizes the result is OK, then at some
point ghc 5.04.1 issues the ominous 
fatal error: scavenge: unimplemented/strange closure
type 63 @ 0x50088000

and for even bigger sizes it just seg faults (see
comments in code for actual sizes).

ghc 6.0.1's output is OK until 5218, from 5219-5221
there's a seg fault immediately following the result,
and from 5222 it just seg faults (this is on RedHat 7.1
w/ 512 MB memory). We even tried the ghc 6.2 CVS
version from 10/07/03, but it's the same problem as 6.0.1.

I would like to use both unsafe versions as I'm trying
to avoid copying in order to reduce the process'
footprint. My array usage would be single threaded so
strict arrays with in-place update would be nice to have.

Cheers,
Nils Ellmenreich 
(nils at fmi dot uni dash passau dot de)
Trac metadata
Trac field Value
Version 6.0.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution ResolvedFixed
Component Runtime System
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