Opened 2 years ago

Closed 18 months ago

#7762 closed bug (fixed)

when using lots of memory: internal error: evacuate(static): strange closure type 4

Reported by: rthiemann Owned by: simonmar
Priority: highest Milestone: 7.8.1
Component: Runtime System Version: 7.0.4
Keywords: Cc: simonmar
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description (last modified by igloo)

resample: internal error: evacuate(static): strange closure type 4
    (GHC version 7.0.4 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Bug occurs reproducable after running the main program for around 8 minutes and consuming 25 GB of RAM.

ghc -rtsopts --make Main -o main
./main +RTS -K3000m -RTS > someFile.txt

Attachments (1)

source.tgz (5.6 KB) - added by rthiemann 2 years ago.

Download all attachments as: .zip

Change History (11)

Changed 2 years ago by rthiemann

comment:1 Changed 2 years ago by ezyang

  • Status changed from new to infoneeded

Hi, can you try to reproduce with 7.6 or a latest nightly? 7.0.4 is rather old at this point...

comment:2 Changed 2 years ago by rthiemann

  • Status changed from infoneeded to new

Ok, some further experiments with other ghc versions than 7.0.4:

  • Using ghc 6.8.3, there is no crash, but the computation is now running since 24 hours.
  • Using ghc 7.6.2, a segmentation fault occurs after having produced 31064352 bytes of output (after 6 minutes of computation)
  • Using ghc 7.6.2 and compiling with -O2, a segmentation fault occurs after having produced 53506464 bytes of output (after 4 minutes of computation)
  • Using ghc 7.7.20130310, a segmentation fault occurs after having produced 39176544 bytes of output (after 6 minutes of computation)
  • Using ghc 7.7.20130310 and compiling with -O2, the program finishes without any error after 8 minutes of computation with a peak memory usage of 40 GB, having produced 100773712 bytes of output.

comment:3 Changed 2 years ago by igloo

  • Description modified (diff)
  • difficulty set to Unknown

comment:4 Changed 2 years ago by igloo

Thanks for the report.

I just tried compiling with -debug and running with -DS with a 1G memory limit, but unsurprisingly it just ran out of memory.

comment:5 Changed 2 years ago by igloo

  • Milestone set to 7.8.1
  • Summary changed from internal error: evacuate(static): strange closure type 4 to when using lots of memory: internal error: evacuate(static): strange closure type 4

comment:6 Changed 19 months ago by simonmar

  • Owner set to simonmar
  • Priority changed from normal to highest

comment:7 Changed 18 months ago by simonmar

  • Cc simonmar added

I can reproduce this, investigating...

comment:8 Changed 18 months ago by Simon Marlow <marlowsd@…>

In 36b042fbf60210ab6859d96e5b4b5e121085816d/ghc:

Make integer overflow less likely to happen (#7762)

The particular problematic code in #7762 was this:

            nat newSize = size - n;
            char *freeAddr = MBLOCK_ROUND_DOWN(bd->start);
            freeAddr += newSize * MBLOCK_SIZE;
                        ^^^^^^^^^^^^^^^^^^^^^^  OVERFLOW!!!

For good measure, I'm going to fix the bug twice.  This patch fixes
the class of bugs of this kind, by making sure that any expressions
involving BLOCK_SIZE or MBLOCK_SIZE are promoted to unsigned long.  In
a separate patch, I'll fix a bunch of individual instances (including
the one above).

comment:9 Changed 18 months ago by Simon Marlow <marlowsd@…>

In b724cd41a0aa1c650a48843efac42e85861eb9c6/ghc:

Turn several nats into StgWord to avoid potential integer overflow (#7762)

comment:10 Changed 18 months ago by simonmar

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.