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,245
    • Issues 5,245
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 562
    • Merge requests 562
  • 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
  • #5071
Closed
Open
Issue created Mar 31, 2011 by guest@trac-guest

GHCi crashes on large alloca/allocaBytes requests

GHCi, and ghc, seems to exit (crash?) on certain types of memory allocation exceptions.

The FFI addendum says that the allocation functions should be able to return null: http://www.cse.unsw.edu.au/\~chak/haskell/ffi/ffi/ffise5.html\#x8-230005

Section 5.8 says this:

If any of the allocation functions fails, a value of Ptr.nullPtr is produced. If free or reallocBytes is applied to a memory area that has been allocated with alloca or allocaBytes, the behaviour is undefined. Any further access to memory areas allocated with alloca or allocaBytes, after the computation that was passed to the allocation function has terminated, leads to undefined behaviour. Any further access to the memory area referenced by a pointer passed to realloc, reallocBytes, or free entails undefined behaviour.

In practice, code examples and documentation appear to rely on alloca NOT returning a nullPtr:

  • http://en.wikibooks.org/wiki/Haskell/FFI
  • http://www.haskell.org/haskellwiki/HSFFIG/Examples
  • http://book.realworldhaskell.org/read/interfacing-with-c-the-ffi.html

I reported this on the libraries list, and offered a documentation tweak, and I was asked to create a ticket: http://www.haskell.org/pipermail/libraries/2011-March/016117.html

That email has details about the testing I did at the time to see the crashing behavior in ghci. I was using ghc 7.0.2 on 64bit windows, but this also appears to affect 7.0.3 on linux. It's likely that other versions of ghc are affected.

My recommendation would be to make the exception thrown by alloca catchable. Possibly offering an alternative to alloca, say alloca', that can produce a nullPtr instead of using exceptions. I would advice against changing the existing alloca function to produce nullPtr as that could make a lot of existing code unsafe.

For example, it would be nice if the following printed "exception", instead of exiting:

$ ulimit -d 100000 -m 1000000 -v 100000
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
$ ./Alloca 
Alloca: out of memory (requested 2148532224 bytes)
$ cat Alloca.hs
import Foreign
import Foreign.Marshal
import Foreign.Marshal.Alloc
import GHC.Exception
import System.IO.Error

main :: IO ()
main = do
  (allocaBytes maxBound compare)
    `catch` (\_ -> print "exception")
  where
  compare p = print ((nullPtr :: Ptr Int) == p)
Trac metadata
Trac field Value
Version 7.0.3
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC dagitj@gmail.com
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