diff options
| author | Simon Marlow <marlowsd@gmail.com> | 2010-12-09 11:40:05 +0000 |
|---|---|---|
| committer | Simon Marlow <marlowsd@gmail.com> | 2010-12-09 11:40:05 +0000 |
| commit | a278f3f02d09bc32b0a75d4a04d710090cde250f (patch) | |
| tree | 1f6fc7dd617de453f7b0ee9b8c3f69cb74caa24b /rts/Schedule.c | |
| parent | 47808bdc0bae8e5ba2910c85ea6c0699af01e97c (diff) | |
| download | haskell-a278f3f02d09bc32b0a75d4a04d710090cde250f.tar.gz | |
Catch too-large allocations and emit an error message (#4505)
This is a temporary measure until we fix the bug properly (which is
somewhat tricky, and we think might be easier in the new code
generator).
For now we get:
ghc-stage2: sorry! (unimplemented feature or known bug)
(GHC version 7.1 for i386-unknown-linux):
Trying to allocate more than 1040384 bytes.
See: http://hackage.haskell.org/trac/ghc/ticket/4550
Suggestion: read data from a file instead of having large static data
structures in the code.
Diffstat (limited to 'rts/Schedule.c')
| -rw-r--r-- | rts/Schedule.c | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/rts/Schedule.c b/rts/Schedule.c index 5169895631..bf39c0ac14 100644 --- a/rts/Schedule.c +++ b/rts/Schedule.c @@ -1025,6 +1025,10 @@ scheduleHandleHeapOverflow( Capability *cap, StgTSO *t ) blocks = (lnat)BLOCK_ROUND_UP(cap->r.rHpAlloc) / BLOCK_SIZE; + if (blocks > BLOCKS_PER_MBLOCK) { + barf("allocation of %ld bytes too large (GHC should have complained at compile-time)", (long)cap->r.rHpAlloc); + } + debugTrace(DEBUG_sched, "--<< thread %ld (%s) stopped: requesting a large block (size %ld)\n", (long)t->id, what_next_strs[t->what_next], blocks); |