Re: [Caml-list] Do you use a debugger with OCaml? If not, why not?

["Török Edwin" <edwin+ml-ocaml@etorok.net>]

On 11/25/2015 06:52 PM, Michael Grünewald wrote:
> 
>> On 25 Nov 2015, at 17:16, Anton Bachin <antonbachin@yahoo.com> wrote:
>>
>> I always use prints and never debuggers when I have access to the
>> source, in any language. I use debuggers when reverse-engineering
>> binaries, however. As for why – setting up breakpoints, trying to
>> examine values usually takes more time for me than adding some
>> prints and reading and understanding the resulting trace. Perhaps
>> it only seems that way, but that has been my habit for a very long
>> time.
> 
> [ ... ]
> 
> Instead of print-peppering, I prefer to use structured failures
> (like the success monad https://github.com/michipili/lemonade)
> giving context for the failure, or improved logging capacities.

I use tools that I am familiar with when debugging because I don't want to focus on two things (learning a new tool and tracking down/fixing a bug).

For Lwt what helps is to add certain "labels" to a stack at well-known phases in the code (for example the HTTP method and URL as soon as request processing starts using Lwt.key), then the warning/exception
will have some context and helps towards creating a reproducible testcase.

I'd love to be able to use ocamldebug's functionality, but all my OCaml programs are compiled to native code which rules ocamldebug out for the moment.
Ideally I'd like to have something like http://rr-project.org/, unfortunately that doesn't work on my CPU (yet).

Additional logging is my preferred method too: sometimes I just add a printf, but often it is Lwt.log hidden behind a --debug flag,
and I keep these even after the bug is fixed.
I also try to turn debug/verbose mode of libraries (OCamlNet, Ocsigen, ..) where possible.

Often all I know about a problem is a warning or exception logged long ago, and if its Lwt then the stacktrace usually stops at map or some other uninteresting function,
which makes it hard to find the real origin of a bug.
What helps is to add certain "labels" to a stack at well-known phases in the code (for example the HTTP method and URL as soon as request processing starts using Lwt.key), then the warning/exception
will have some context and helps towards creating a reproducible testcase.
Once there is a testcase it is sometimes enough to observe the inputs/outputs using wireshark, sometimes more debugging has to be added.
The hardest ones to debug are probably bugs where timing matters (timeouts, intentional retry delays, etc.).

I would say this is exactly the way I'm debugging C multi-process/multi-threaded server applications too, not necessarily an efficient one though.
Some colleagues always use gdb on C code, but I find grepping logfiles more efficient.
For hard to reproduce bugs you can turn on debug mode - even on quasi-production servers for brief periods of time - , and analyze the logs later (quite likely few GB).

I haven't spent much time debugging single applications that are not networked, but when I'm writing new code/new module I usually just use utop (either directly or from (Spac)Emacs).

There is one case that requires a different debugging technique: SIGSEGV (quite rare, but quite time consuming to track down).
Then I use gdb to get a stacktrace, it is almost certainly a bug in C code.
Debugging it is similar to the approach I take when debugging incorrect code generated by C compilers (I had quite a few of these in C applications, more than bugs I had in C code linked with OCaml apps).
That is: build with debugging aids (in this case OCaml's debug runtime and Gc.compact called often), try to find a reproducible testcase, and then try to minimize the testcase
(either manually or via tools like delta.tigris.org). Often this means adding additional sanity checks to the C code being debugged.
Once there is a testcase of reasonable size then there is usually enough information to fix it or report to upstream bugtracker.
Unfortunately C debugging aids like address sanitizer or valgrind are not easily usable with OCaml C runtime/bindings, because they would only detect corruption at the C level,
and wouldn't always detect when C code corrupts OCaml's heap.

-- 
Edwin Török | Co-founder and Lead Developer

Skylable open-source object storage: reliable, fast, secure
http://www.skylable.com