Any tips and tricks to debug Koka code?

[AZMCode]

I'm in the midst of trying to understand why a program of mine is currently segfaulting (I figure I probably can't fix it, but at least avoid it), and I'm having a hard time trying to use lldb to debug the program.

Problem is that all that I got (If I'm right about this, which I may not) is the transpiled C code to put up breakpoints and take a stack trace at the moment of segfaulting.

Is there an lldb plugin that allows me to see koka code instead of the C code, or any other way of debugging other than just putting a bunch of printlns everywhere to debug this?

[TimWhiting]

Sorry, at the moment this is obviously an area that Koka lacks good tooling. I've been successful in debugging some things by setting up lldb in vscode to use the compiled C code output directory, so at least I can put breakpoints in the C functions across all of the dependencies. Part of the issue is that the transpiled C code breaks up functions at every potential effectful call, which duplicates a bunch of code and makes it so that you have to insert many breakpoints which would otherwise be a single spot in Koka's source.

I read a paper recently which presents a "simple" way to add debugging / lldb support for higher level languages that compile to C. https://github.com/BuildIt-lang/d2x
It would be interesting to adapt or integrate it into Koka (but I don't know how "simple" simple really is). I might try to see if I can get it integrated in some weekend, but doubt I can spend more than a weekend on it due to higher priorities. Feel free to give it a try if you think this would be something that would save you more time in the long run! Unfortunately it looks like it is written in C++ and Koka currently emits C code.

Obviously Koka is intended to be a sound language. So it should never segfault, other than if you run out of stack (a common occurrence unfortunately, due to the many small functions that get built up as continuations). I think it should be recommended to always make sure you set your terminal / process settings to have unlimited stack. This usually solves issues developers have encountered with segfaulting in Koka.

[AZMCode]

It might just be infinite recursion that's causing me trouble, looking closer in the call stack. I'll check all my code and try to suss out the bug. I appreciate the pointer!

I'll look into the setting unlimited stack space, but if there's some infinite recursion going on i doubt it would be much use.

Interestingly nowhere in my program is there a div effect, but I do use the many parser combinator
(Which i happened to have asked about relatively recently #489). I assume somewhere I allowed a zero-progress parser through to many, which may have caused infinite recursion, at least that's the hypothesis for the time being.

[TimWhiting]

Great: for MacOS / Linux it usually is something as simple as ulimit -s unlimited (setting the user limit for stack to unlimited), then the rest of the shell session should have unlimited stack. There should be a path to the executable printed in the VSCode Koka Language Server terminal, that you can just copy and paste to another terminal.

As far as the many issue: I think #489 (reply in thread) suggested by @chtenb was a good solution for helping you debug something like this in particular.

[AZMCode]

Just as a curiosity, why does Koka fail with a Segfault instead of a Stack overflow in this case?

[TimWhiting]

Same reason C doesn't. I think C++ does have stack overflow exceptions though maybe as part of the exception handling machinery.

https://stackoverflow.com/questions/35223114/detecting-stack-overflows-during-runtime-beforehand

We'd have to add something to function headers to detect when we are getting close to the stack limit, which involves overhead. Not saying that it wouldn't be useful and probably a good idea, but we'd need to figure out whether to put it on every function (probably too much), only on recursive functions that don't have tail calls, or when handlers get inserted for example.

Essentially we would need to define how close is 'close' and ensure the checks are inserted frequent enough and keeping in mind the definition of 'close' to not miss stack overflows which would totally miss the point of supporting stack overflow detection, but also not too frequent to affect performance. One potential avenue could be to have a flag to disable it in some sort of optimization level, and always enable detection on debug mode. Honestly it is likely to come up enough in debug mode that you mitigate it or set appropriate stack limits before compiling it in an optimized mode. As such I think it would be useful to add to debug mode at a fairly frequent interval maybe?

[chtenb]

If you're on windows, have a look in the event viewer. Segfaults show up there with an error code that should indicate the nature of the fault.

[AZMCode]

Thanks, I swore C had stack overflows, I must've simply misremembered. I appreciate the patience too.

[TimWhiting]

No problem, hope you got everything figured out!

[AZMCode]

I did!

I ended up writing a script in koka to automate my backups, hopefully more regularly now. I'd open source it if it wasn't so primitive.

The effects really helped for this specific use case since I can ensure (through the initially and finally primitives) that whenever a command fails (a partition cannot unmount, the drive cannot be unlocked, etc) I can always ensure proper cleanup, no matter the path of execution. The code looks much nicer now too. This is the main function:

fun main/main(): <exn,io> unit
  val c = config.force()
  "The configuration is as follows. Do you want to continue?".println()
  c.show().println()
  confirm()
  with finally  (fn( ) -> close  ())
  with initially(fn(_) -> open   ())
  with finally  (fn( ) -> unmount())
  with initially(fn(_) -> mount  ())
  backup()

I did end up writing a custom config format too, which is why I asked about the parser combinators, and my (now solved) bug with many diverging when the effect signature said it didn't.

It all works fully now, to the best of my ability to check in a dry run, and I'm going to test it live through the night.