throw() eats memory and hangs on repl

[chtenb]

Reproduction
Enter the koka repl and type throw("hello")

Observed behavior
The repl hangs and the memory usage of the koka process increases very rapidly.

Other remarks
This also happens when calling a function that throws from the repl.
I've also encountered a segfault of a throw call in the context of a larger program, which also happens outside the repl (i.e. when compiling normally). Could that be related?

[TimWhiting]

So it doesn't even produce a binary. I've narrowed it down to getting stuck in the second type checking pass for the interpreter - after wrapping the result in a println(show(@expr())).

I believe this is happening because expr has a polymorphic return type. We should instantiate top level polymorphic variables in interpreter expressions to unit. Separately we need to figure out why this causes the inference to spin in a loop instead of failing.

I do not think this relates to segfaults outside the repl. Do you have a reproducible example for that? I know we fixed some segfault issues for the release at the end of December. Is this something that has happened since then?

[chtenb]

I do not think this relates to segfaults outside the repl. Do you have a reproducible example for that? I know we fixed some segfault issues for the release at the end of December. Is this something that has happened since then?

Yeah, I hoped your fixes had also solved my cases, but it still happens with the newest release unfortunately :) I haven't been able find a small reproduction so far, they only seem to appear in somewhat larger programs, and I don't have a hunch yet in what causes them.

[TimWhiting]

Do you use finally? I know of this outstanding issue that relates to that construct.
#360

It also seems to be related to non-resumptive handlers, maybe they could have the same root cause.

The other question is do you use named handlers? I know of this issue that relates to those: #356.

Finally most other segfaults I know about are caused by not having enough stack space: #305

[chtenb]

I'm not using any custom effects in that particular piece of code. It's also not a stackoverflow: i've confirmed in the windows event viewer that the process ended with an error code that corresponds to a memory access violation. If I can get a reasonably small reproduction I'll create an issue.

[daanx]

Ah nice one -- turns out it was just going into exponential search for a show function of type a -> string :-) Writing throw("hi") : () works for example. I thought the breath-first search algorithm would prevent this but alas -- I needed to add a further check to prune infinite expansions -- this may need further refinement but at least it fixes the issue (giving a type error that there is no appropiate show ).

Thanks for spotting this! I am trying to specify formally the exact resolution algorithm and having more test cases helps finding rough parts.