Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • 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 4,842
    • Issues 4,842
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 457
    • Merge requests 457
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #188

Closed
Open
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