Opened 3 years ago

Closed 2 years ago

#9579 closed bug (fixed)

Runtime suggests using +RTS when that's not possible

Reported by: gintas Owned by:
Priority: low Milestone: 8.0.1
Component: Runtime System Version: 7.9
Keywords: newcomer Cc: simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D767
Wiki Page:

Description

I just ran into a stack overflow in an application, and GHC told me:

Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize -RTS' to increase it.

I tried to specify +RTS and got an error saying "Most RTS options are disabled. Link with -rtsopts to enable them."

The runtime should not suggest using +RTS when that is not possible.

Change History (21)

comment:1 Changed 3 years ago by rwbarton

But then how would anyone learn how to increase the stack limit?

(Also, isn't the default stack limit set to be most of your RAM already in 7.8? Are you really using ghc 7.9?)

comment:2 Changed 3 years ago by dfeuer

It sounds like what you'd really like is an extended error message when RTS options are not enabled.

comment:3 Changed 3 years ago by rwbarton

Actually I see one case where not suggesting using +RTS makes sense: when the user has installed a Haskell application like pandoc through their package manager, if it wasn't built with -rtsopts, the suggestion to link with -rtsopts will be rather unhelpful.

I suppose we could add an option -no-rtsopts-suggestions and encourage people distributing binaries to build with either -rtsopts or -no-rtsopts-suggestions...

comment:4 Changed 3 years ago by gintas

Indeed I was running a precompiled binary that ran out of stack space and gave me this message. Simply rephrasing as "Relink with -rtsopts and use +RTS -Ksize -RTS" would already be nicer.

comment:5 Changed 3 years ago by thomie

Keywords: newcomer added

comment:6 Changed 3 years ago by thomie

Milestone: 7.12.1
Owner: simonmar deleted

comment:7 Changed 3 years ago by javran

I'm newcomer and thinking about working on this ticket. I investigated a little bit, there are currently 3 places where a RTS suggestion appears:

  • in StackOverflowHook of rts/hooks/StackOverflow.c:
fprintf(stderr, "Stack space overflow: current size %" FMT_Word " bytes.\nUse `+RTS -Ksize -RTS' to increase it.\n", stack_size);
  • in OutOfHeapHook of rts/hooks/OutOfHeap.c
if (heap_size > 0) {
    errorBelch("Heap exhausted;\nCurrent maximum heap size is %" FMT_Word " bytes (%" FMT_Word " MB);\nuse `+RTS -M<size>' to increase it.",
        heap_size, heap_size / (1024*1024));
} else {
    errorBelch("out of memory");
}
  • in nextEra of rts/ProfHeap.c:
if (era == max_era) {
    errorBelch("maximum number of censuses reached; use +RTS -i to reduce");
    stg_exit(EXIT_FAILURE);
}

And the error message saying "Most RTS options are disabled." comes from rts/RtsFlags.c. It seems that we need to know the value of RtsOptsEnabledEnum enabled to tell whether RTS options are available, but this value is only passed around setupRtsFlags and procRtsOpts during command line parsing. Is there some way to check the availability of RTS options for 3 places I mentioned above?

comment:8 Changed 3 years ago by thomie

Couldn't you store RtsOptsEnabledEnum in the RtsFlags struct? See includes/rts/Flags.h, initialization in rts/RtsFlags.c. Then use it those 3 places.

comment:9 Changed 3 years ago by javran

Owner: set to javran

comment:10 Changed 3 years ago by thomie

Differential Rev(s): Phab:D767

comment:11 Changed 3 years ago by javran

almost done patching up GHC for better suggestions.

What about adding options like -no-rtsopts-suggestions? I don't see much discussion here.

I think The bug described in OP will be solved with the current patch and we should open another ticket for adding new options.

@rwbarton would you mind opening another ticket and give more details about the option you've proposed?

comment:12 Changed 3 years ago by Erik de Castro Lopo <erikd@…>

In 51af102e5c6c56e0987432aa5a21fe10e24090e9/ghc:

Better hints when RTS options not available (Trac #9579)

This patch provides user with a better hint when most RTS options
are not available (not compiled with `-rtsopts`).

A new field "rtsOptsEnabled" is added into RtsFlags.MiscFlags to
tell the availablity of RTS options.

Some concerns:
* Unlike other flag fields in "libraries/base/GHC/RTS/Flags.hsc",
  "RtsOptsEnabled" is defined in "includes/RtsAPI.h" and lacks
  constant macros. Therefore In "GHC.RTS", "RtsOptsEnabled" simply
  derives Enum instance and reads as of type "CInt".

* There are other ways to change RTS options (e.g. `-with-rtsopts`),
  but it might be too verbose to mention.

Test Plan: validate

Reviewers: austin, hvr, thomie, simonmar

Reviewed By: thomie

Subscribers: thomie, rwbarton

Differential Revision: https://phabricator.haskell.org/D767

GHC Trac Issues: #9579

comment:13 Changed 3 years ago by bherzog

The test-cases are a bit too fragile. All three of the T9579_stackoverflow_* tests fail for me because of differences in the reported stack size:

@@ -1,2 +1,2 @@
-Stack space overflow: current size 99136 bytes.                                
+Stack space overflow: current size 99208 bytes.

comment:14 Changed 3 years ago by Austin Seipp <austin@…>

In 477f514f6ebcf783810da93e2191e4b6ea65559b/ghc:

rts: add "-no-rtsopts-suggestions" option

Depends on D767

Setting this flag prevents RTS from giving RTS suggestions like "Use
`+RTS -Ksize -RTS' to increase it."

According to the comment @rwbarton made in #9579, sometimes "+RTS"
suggestions don't make sense (e.g. when the program is precompiled and
installed through package managers), we can encourage people to
distribute binaries with either "-no-rtsopts-suggestions" or "-rtsopts".

Reviewed By: erikd, austin

Differential Revision: https://phabricator.haskell.org/D809

GHC Trac Issues: #9579

comment:15 in reply to:  13 Changed 3 years ago by javran

Replying to bherzog:

The test-cases are a bit too fragile. All three of the T9579_stackoverflow_* tests fail for me because of differences in the reported stack size:

@@ -1,2 +1,2 @@
-Stack space overflow: current size 99136 bytes.                                
+Stack space overflow: current size 99208 bytes.

I'll try to fix this, what I have in mind is to pipe stderr to replace the actual number with a constant string, as the actual number is not important for testing this.

Any ideas?

comment:16 Changed 3 years ago by Erik de Castro Lopo <erikd@…>

In 4b8b4ce12a1b5f682071a27bc313649fa50e0e91/ghc:

Fix fragile T9579 tests

Fix fragile tests according to comment 13 of #9579 (by @bherzog)

Done by capturing stderr and replace `xx bytes` with `NUM bytes`
(literal).

Some numbers like `(1 MB)` would still remain, but I think
it's safe to assume the actual difference in bytes (on different
architectures) is too small to have an effect on the rounded megabyte
value.

Test Plan: validate

Reviewers: erikd, austin

Reviewed By: erikd, austin

Subscribers: erikd, bgamari, thomie, bherzog

Differential Revision: https://phabricator.haskell.org/D882

GHC Trac Issues: #9579

comment:17 Changed 3 years ago by javran

Resolution: fixed
Status: newclosed

comment:18 Changed 3 years ago by javran

Things mentioned here are all done so I mark this ticket as closed. :) Feel free to open if there are still questions.

comment:19 Changed 2 years ago by goldfire

Owner: javran deleted
Resolution: fixed
Status: closednew

The T9579 tests are all failing during validation on my Mac.

For example:

Actual stdout output differs from expected:
--- ./T9579_outofheap_rtsall.stdout.normalised	2015-06-16 14:06:15.000000000 -0400
+++ ./T9579_outofheap_rtsall.run.stdout.normalised	2015-06-16 14:06:15.000000000 -0400
@@ -1,4 +1,4 @@
 T9579_outofheap_rtsall: Heap exhausted;
-T9579_outofheap_rtsall: Current maximum heap size is NUM bytes (1 MB).
+T9579_outofheap_rtsall: Current maximum heap size is 1048576 bytes (1 MB).
 T9579_outofheap_rtsall: Use `+RTS -M<size>' to increase it.
 251
\ No newline at end of file
*** unexpected failure for T9579_outofheap_rtsall(normal)

comment:20 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:21 Changed 2 years ago by bgamari

Resolution: fixed
Status: newclosed

goldfire, the issue that you are observing actually appears to be a difference in sed's behavior on OS X. The number in the error message is supposed to be replaced by NUM with sed -e 's/[0-9]* bytes/NUM bytes/g'. Perhaps someone with access to an OS X box could shed some light on this.

I'm going close this in favor of #11093.

Note: See TracTickets for help on using tickets.