Stackoverflow in RascalMPL while running the test framework about rascal HOT 17 OPEN

Here is the like to the project

https://github.com/BlackHart98/sqlpolyglot/blob/main/src/main/rascal/spark/prettyprint/Tests.rsc#L8

from rascal.

The trigger is this definition which results in an infinite recursion:

public str toString(ViewId viewId)="<toString(viewId)>";

I found this by setting :set debugging true in VScode and stepping through the code (with "step into"), until I got stuck myself in this place :-)

The stackoverflow error thus genuine, so that's not the bug, but the report of this stackoverflow is bad. It should have given a stack trace like so:

...  toString(ViewId viewId)
...  toString(ViewId viewId)
...  toString(ViewId viewId)
...  toString(ViewId viewId)
...  toString(ViewId viewId)
...

Such than easy diagnosis can be made. I'll look into fixing that in the Rascal interpreter. In the mean time this definition would be a good workaround:

public str toString(propRef(list[Identifier] ids))="<for (id <- ids) {><id> <}>"[..-1];

Yeah figured that out belatedly, but like you said the report is bad but is genuine

from rascal.

Thinking about the fix now. not so easy :-) I need to get some stack space to create the error, but I also need the information on the stack to create the error message.

from rascal.

@BlackHart98 I don't know. What do you mean by "resolves the project". Is that the code for starting a terminal or when you read a file with the project:/// scheme? or something else? It's unrelated to this I think, but could also be interesting to look at in a different issue :-)

Thanks for reporting this one anyway. The solution is underway but I need some advice from @DavyLandman to finalize it.

Maybe my choice of word was wrong, what I meant is the it takes time to load the rascal project after I save changes(on VSCode)

from rascal.

I think it would be nice to share your project, as quite some stuff is going wrong here.

from rascal.

from rascal.

Does it also happen if you call testCreateDB() directly?

from rascal.

I reproduced the behavior. The stackoverflows happen when this test is called:

test bool testAlterV() {
  loc file = |project://sqlpolyglot/src/main/rascal/spark/examples/alterv.ssql|;
  return prettyCond(file);
}

if I remove this test, everything runs smoothly.

from rascal.

The trigger is this definition which results in an infinite recursion:

public str toString(ViewId viewId)="<toString(viewId)>";

I found this by setting :set debugging true in VScode and stepping through the code (with "step into"), until I got stuck myself in this place :-)

The stackoverflow error thus genuine, so that's not the bug, but the report of this stackoverflow is bad. It should have given a stack trace like so:

...  toString(ViewId viewId)
...  toString(ViewId viewId)
...  toString(ViewId viewId)
...  toString(ViewId viewId)
...  toString(ViewId viewId)
...

Such than easy diagnosis can be made. I'll look into fixing that in the Rascal interpreter. In the mean time this definition would be a good workaround:

public str toString(propRef(list[Identifier] ids))="<for (id <- ids) {><id> <}>"[..-1];

from rascal.

Looks like an interesting project @BlackHart98 !

from rascal.

Simple reproduction:

rascal>int f(int i) = f(i);
int (int): function(|prompt:///|(0,20,<1,0>,<1,20>))
rascal>f(2)
java.lang.StackOverflowErrorjava.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.StackOverflowError
java.lang.NoClassDefFoundError: Could not initialize class java.lang.StackTraceElement$HashedModules
(internal error)
        at $shell$(|main://$shell$|)

java.lang.NoClassDefFoundError: Could not initialize class java.lang.StackTraceElement$HashedModules
Unexpected (uncaught) exception, closing the REPL: 
java.lang.NoClassDefFoundError: Could not initialize class java.lang.StackTraceElement$HashedModulesjava.lang.NoClassDefFoundError: Could not initialize class java.lang.StackTraceElement$HashedModules
java.io.IOException: Stream closed
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class java.lang.StackTraceElement$HashedModules

Exception: java.lang.NoClassDefFoundError thrown from the UncaughtExceptionHandler in thread "main"

from rascal.

The problem seems to be this code which catches the StackOverflowError just below the deepest stack frame, and then calls more code which needs stack space to print the error:

In Expression.CallOrTree.interpret():

catch (StackOverflowError e) {
				e.printStackTrace();
				throw RuntimeExceptionFactory.stackOverflow(this, eval.getStackTrace());
			}

from rascal.

Looks like an interesting project @BlackHart98 !

I also noticed that Rascal resolves the project a lot slower, hat could be the issue?

from rascal.

@BlackHart98 I don't know. What do you mean by "resolves the project". Is that the code for starting a terminal or when you read a file with the project:/// scheme? or something else? It's unrelated to this I think, but could also be interesting to look at in a different issue :-)

Thanks for reporting this one anyway. The solution is underway but I need some advice from @DavyLandman to finalize it.

from rascal.

Ah yes. No that's a "feature" of the slow type-checker. The more modules you edit, the more it needs to type-check and the slower it becomes. We are working on a compiled version of that as we speak to make that faster.

from rascal.

If you keep the .tpl files in your target folder, the type-checker will reuse as much as possible. So that helps. I'd put the target folder in your .gitignore and remove it from git with git rm -r target. That way the time stamps of the .tpl files stay in order when you git pull or git push and you have less work for the typechecker usually.

from rascal.

Thanks, :-)

from rascal.