This project is read-only.

Stack overflow with LanguageProvider.GetEngine().Evaluate() but not IronScheme.Console.exe

Sep 12, 2012 at 10:41 PM

I'm running into a problem where I get a stack overflow when using

LanguageProvider slp = ScriptDomainManager.CurrentManager.GetLanguageProvider(typeof(IronSchemeLanguageProvider)); 
ScriptEngine se = slp.GetEngine();
se.Evaluate("(load \"" + modelFileName + "\")");
from my C# code, but not when using the IronScheme console and using
(load filename)

For a moment I hoped the issue was the one you've mentioned about the .Net 2 vs. .Net 4 install, but using the .Net 4 installer didn't help.

I'm using IronScheme for model description (think chemical systems modeling) so the file I'm loading is just a series of statements defining chemical species, parameters (constants), and reactions between the species. Each of these statements becomes a few calls to create objects implemented in C# so the console behavior seems consistent with my impression that there shouldn't be any (significant) recursive behavior.

The overflow stack trace looks like this:

ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0xdf bytes	
ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0x191 bytes	
ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0x191 bytes	
ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0x191 bytes	
ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0x191 bytes	

Lines 6 through 2331 removed.

 ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0x191 bytes	
 ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0x191 bytes	 
 ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0x191 bytes	
 ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0x191 bytes	
 ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match-each-any$1987(Microsoft.Scripting.CodeContext $context, object e, object m*, object s*, object ae*) + 0x191 bytes	
 ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match*$1990(Microsoft.Scripting.CodeContext $context, object e, object p, object m*, object s*, object ae*, object r) + 0x3ce bytes	
 ironscheme.boot.dll!#.psyntax.expander::syntax-dispatch##match*$1990(Microsoft.Scripting.CodeContext $context, object e, object p, object m*, object s*, object ae*, object r) + 0x291 bytes	
 ironscheme.boot.dll!#.psyntax.expander::parse-top-level-program(object e*) + 0x168 bytes	
 ironscheme.boot.dll!#.psyntax.expander::top-level-expander(object e*) + 0x92 bytes	
 ironscheme.boot.dll!#.psyntax.expander::compile-r6rs-top-level(object x*) + 0x14b bytes	
 ironscheme.boot.dll!#.psyntax.main::load-r6rs-top-level#1#anon#1#2#3#4#5#6$2609(Microsoft.Scripting.CodeContext $context) + 0x77 bytes	
 ironscheme.boot.dll!#.ironscheme.exceptions::dynamic-wind(object in, object proc, object out) + 0x26c bytes	
 ironscheme.boot.dll!#.ironscheme.exceptions::dynamic-wind(object in, object proc, object out) + 0x26c bytes	
 ironscheme.boot.dll!#.psyntax.main::load#1$2583(Microsoft.Scripting.CodeContext $context) + 0x182 bytes	
 ironscheme.boot.dll!#.ironscheme.exceptions::dynamic-wind(object in, object proc, object out) + 0x26c bytes	
>IronScheme.dll!IronScheme.Runtime.Builtins.CallWithCurrentContinuation(object fc1) Line 204 + 0x16 bytes	C#
 ironscheme.boot.dll!#.psyntax.main::with-guard#anon$2576(Microsoft.Scripting.CodeContext $context) + 0x71 bytes	
 IronScheme.dll!IronScheme.Runtime.R6RS.Exceptions.WithClrExceptionHandler(object handler, object thunk) Line 25 + 0x12 bytes	C#
 ironscheme.boot.dll!#.psyntax.main::with-guard(object f) + 0x1be bytes	
 IronScheme.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scripting.CodeContext codeContext, bool tryEvaluate) Line 137 + 0x9a bytes	C#
 IronScheme.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scripting.ScriptModule module) Line 150 + 0x6e bytes	C#
 IronScheme.dll!IronScheme.Runtime.Builtins.CompileCore.AnonymousMethod__e() Line 802 + 0x5d bytes	C#
 IronScheme.dll!IronScheme.Runtime.Builtins.EvalCore(object expr) Line 870 + 0x14 bytes	C#
 ironscheme.boot.dll!#.psyntax.expander::eval(object x, object env) + 0x20b bytes	
 IronScheme.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scripting.CodeContext codeContext, bool tryEvaluate) Line 143 + 0x2a bytes	C#
 IronScheme.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scripting.ScriptModule module) Line 150 + 0x6e bytes	C#
 IronScheme.Scripting.dll!Microsoft.Scripting.Hosting.CompiledCode.Evaluate(Microsoft.Scripting.IScriptModule module) Line 94 + 0x28 bytes	C#
 IronScheme.Scripting.dll!Microsoft.Scripting.Hosting.ScriptEngine.Evaluate(string expression, Microsoft.Scripting.IScriptModule module) Line 319 + 0x43 bytes	C#
 IronScheme.Scripting.dll!Microsoft.Scripting.Hosting.ScriptEngine.Evaluate(string expression) Line 314 + 0x12 bytes	C#

Thoughts?

Thanks,

-Chris

Sep 13, 2012 at 5:11 AM
Edited Sep 13, 2012 at 6:41 PM
Try calling the extension methods instead. ie “(load {0})”.Eval(filename).
Sorry for quick reply (on my way to work)
Sep 13, 2012 at 6:23 PM

Good news/bad news - exactly the same behavior:

Process is terminated due to StackOverflowException.

Sep 13, 2012 at 6:46 PM
Edited Sep 13, 2012 at 6:55 PM

That is weird ;p

It appears from the stacktrace the syntax expansion is running into an infinite loop.

Do you have a snippet to reproduce this behavior? (I just recalled I did help you a while back with some macro's)

Have you tried using the latest build at: http://build.ironscheme.net to confirm it is not a fixed bug?

Edit:

It might also be just running into stack issues. The console loads a file in another thread with a specified stack size to help prevent this (see here ). Using a similar 'pattern' you can try bump up the stacksize too. Also note, this is a compile time issue, so it wont affect runtime code if you compile the code to a library dll.

Update:

If the above is the issue, I would be interested in seeing what kind of syntax/code does cause this kind of issue.

Sep 13, 2012 at 6:59 PM

I'll check against the latest build before bothering you again.

I'll also see about creating a manageable repro case (if necessary).

You may be right about the stack issue -- I may go that direction in the short term until we determine whether it's my problem or an IronScheme issue.

Thanks!

Sep 14, 2012 at 7:35 PM
Edited Sep 14, 2012 at 9:12 PM

Good news/bad news again: good - with the latest build, no stack overflow when called from my code normally, bad - stack overflow when running under the debugger.

I'm suspicious that stack usage with the latest build has changed so we are under the limit and the real issue has only been masked. However, we're good to go unless we have even larger model (Scheme) files which trigger the issue again. In that case I'll revisit generating a repro case.

Thanks.

Sep 14, 2012 at 7:56 PM
Edited Sep 14, 2012 at 7:58 PM
clorton wrote:

Good news/bad news again: good - with the latest build, no stack overflow when called from my code normally, bad - stack overflow when running under the debugger.

I'm suspicious that stack usage has with the latest build has changed so we under the limit and the real issue has only been masked. However, we're good to go unless we have even larger model (Scheme) files which trigger the issue again. In that case I'll revisit generating a repro case.

Thanks.

Good :)

The default stack size is quite small, only 1MB (less on ASP.NET). Given the 10's of MB of heap required just for loading a .NET program, I dont think setting it to 10MB or maybe more even extreme. 

It will be good to diagnose why exactly it needs to recurse so deeply.

Edit: The debugger add extra stack space requirements.