Opened 2 years ago

Closed 2 years ago

#5644 closed bug (fixed)

runtime crash while closing program due to +RTS -M limit

Reported by: tener Owned by: simonmar
Priority: high Milestone: 7.4.1
Component: Runtime System Version: 7.2.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime crash Difficulty:
Test Case: Blocked By:
Blocking: Related Tickets:

Description

When I run a certain program with limited heap size it will sometimes (like in 1/3 cases) exit with internal error message.

The error appears only when the program is terminated because of heap size restriction.

Example here:

Heap exhausted;
Current maximum heap size is 104857600 bytes (100 MB);
use `+RTS -M<size>' to increase it.
heap-overflow: internal error: scavenge_mark_stack: unimplemented/strange closure type 4721296 @ 0x7f8d293bfa78
    (GHC version 7.2.2 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
zsh: abort      ./heap-overflow +RTS -M100m -s

Another one:

Heap exhausted;
Current maximum heap size is 104857600 bytes (100 MB);
use `+RTS -M<size>' to increase it.
heap-overflow: internal error: get_threaded_info
    (GHC version 7.2.2 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
zsh: abort      ./heap-overflow +RTS -M100m -s

If the bug isn't triggered, the result is this (expected):

Heap exhausted;
Current maximum heap size is 104857600 bytes (100 MB);
use `+RTS -M<size>' to increase it.
     434,336,808 bytes allocated in the heap
     227,881,408 bytes copied during GC
     103,529,152 bytes maximum residency (10 sample(s))
       8,582,464 bytes maximum slop
             104 MB total memory in use (0 MB lost due to fragmentation)

                                    Tot time (elapsed)  Avg pause  Max pause
  Gen  0       832 colls,     0 par    0.16s    0.16s     0.0002s    0.0004s
  Gen  1        10 colls,     0 par    0.66s    0.68s     0.0684s    0.2776s

  INIT    time    0.00s  (  0.00s elapsed)
  MUT     time    0.17s  (  0.19s elapsed)
  GC      time    0.82s  (  0.84s elapsed)
  EXIT    time    0.00s  (  0.00s elapsed)
  Total   time    0.99s  (  1.03s elapsed)

  %GC     time      82.5%  (81.4% elapsed)

  Alloc rate    2,505,938,669 bytes per MUT second

  Productivity  17.5% of total user, 16.8% of total elapsed

Sometimes there is not even a crash message from runtime. This is rarer with -M100m, but with -M10m you gets it most of the time:

Heap exhausted;
Current maximum heap size is 104857600 bytes (100 MB);
use `+RTS -M<size>' to increase it.
zsh: segmentation fault  ./heap-overflow +RTS -M100m -s  (HERE should be internal-error message)

Furthermore, with 7.2.2 there is almost always "internal error: scavenge_mark_stack: unimplemented/strange closure type FOO @ BAR", where FOO appears random integer and BAR is random address.

I have several GHC's installed, so I've checked that this bug appeared with GHC 7.0.2. There is no bug for 6.12.3.

Strangely with 7.0.2 there is sometimes a different message. Some varieties I've spotted:

This one also appears on 7.2.2:

internal error: get_threaded_info 

Only seen on 7.0.2:

internal error: update_fwd: unknown/strange object  2580167

There may be more, I didn't run it that many times to check it though.

The program attached triggers the bug. Do "make bug" to compile and run the program.

(Actually there is another bug(?) with this code, but I'm leaving that to another ticket.)

I did all the checking on my Arch Linux 64-bit machine. uname -a:
Linux raptor 3.1.0-4-ARCH #1 SMP PREEMPT Mon Nov 7 22:47:18 CET 2011 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel? GNU/Linux

Attachments (1)

report.7z (1.4 KB) - added by tener 2 years ago.

Download all attachments as: .zip

Change History (5)

Changed 2 years ago by tener

comment:1 Changed 2 years ago by simonmar

  • Milestone set to 7.4.1
  • Owner set to simonmar
  • Priority changed from normal to high

comment:2 Changed 2 years ago by marlowsd@…

commit 5e5d2bae42699f22ca81e0c1a74aa29825f96535

Author: Simon Marlow <marlowsd@gmail.com>
Date:   Fri Nov 18 17:05:44 2011 +0000

    Fix bug in the handling of TSOs in the compacting GC (#5644)

 rts/sm/Compact.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

comment:3 Changed 2 years ago by simonmar

Great bug report, thanks!

comment:4 Changed 2 years ago by simonmar

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