How do you Debug Ocaml?

I also used to use ocamldebug + Emacs, which was quite nice. But after some point it does not show the correct location of execution, so I stop using it and fell back to printf debug :sob:

Does anybody have similar experience?

This may have to do with the directory setup for ocamldebug. I found I need to explicitly dig out all directories of the relevant .cmi files within my .opam subdirectories, for all libraries that I want to be able to trace execution in. I then listed these as #directory directives in .ocamldebug.

1 Like

found I need to explicitly dig out all directories of the relevant .cmi files within my .opam subdirectories, for all libraries that I want to be able to trace execution in. I then listed these as #directory directives in .ocamldebug.

Yeah, I know. But for my case, ocamldebug shows the funny place within a file.

My problem occurs several years ago so it may be already solved, however.

Yes. But only when my source files are utf-8 encoded instead of latin-1.

(Including comments…)

1 Like

I’m not sure about my files. Need to check.

But now I use Atom as an editor so maybe this is moot (at least for me).

Feel free to open issue reports if (the most recent version of) ocamldebug is not behaving correctly.

Note that there is a chronic lack of people interested in helping maintain and improve ocamldebug; the Coq people are heavy users of it, and they have bugreports and feature requests, but we currently lack the manpower to address some of them. If someone around is an ocamldebug user, and would be willing to invest some effort into looking at the codebase and contributing to it (for example, there is a patchset from whitequark that implements debugging of dynlinked code, but I haven’t been able to find a motivated reviewer yet), that could be very helpful.

2 Likes

there is a patchset from whitequark that implements debugging of dynlinked code

That was where I got stumped when using ocamldebug, i.e. debugging dynlinked ocaml code. It could indeed be quite useful. Is this patch a GPR perhaps?

I just found http://mshinwell.github.io/libmonda/ but haven’t tried it yet. Not sure if it is up-to-date with regards to 4.05/4.06. This would be very useful tool to have in 4.07 since gdb is quite powerful.

This was before github, so the patch is on Mantis in MPR#6792. The patch was against 4.02, so we would first need someone to port it to a more recent OCaml version (4.05 or 4.06), and to test the result. Unfortunately porting is not trivial because there were other related changes to the runtime in between (some features of the patch are subsumed by work that went into making backtraces work well, if I remember correctly). Once we have got a working patch on a recent OCaml version, we can ask the Coq people to test it and, if it works for them, propose it for upstream inclusion.

This is not easy work, but it would be very helpful to various people.

Ok. Thanks for the update.

There is another GPR(https://github.com/ocaml/ocaml/pull/574) which if merged would make a lot of ocamlers happy when debugging. Could we vote - if such a mechanism exists in ocaml - for this feature to be included in 4.07 perhaps.

1 Like

Could we vote - if such a mechanism exists in ocaml - for this feature to be included in 4.07 perhaps

You can vote for whatever you like, but it’s not going to change the man power available to work on OCaml.

The best way to vote is to contribute to the PR, either by the actual code or, at least, by reviewing and testing. These are not just empty words, that you may have heard lots of time. When you actually become involved in this PR, you may notice that the developer became much more motivated. It is very dull to develop something, about which nobody cares. So vote by your active involvement. Make a fuss about it, and it will get into the trunk soon.

1 Like

I generally approve of this message as long as we understand “fuss” as a productive behavior where you make development easier (by reviewing and testing, for example), rather than just noise, which doesn’t necessarily help.

2 Likes

You can vote for whatever you like, but it’s not going to change the man power available to work on OCaml.

True. I was thinking more in terms of motivating the current available man power. The logic being that people who are capable will be (more?) motivated to implement features if they knew/know that the feature is desired/wanted by the community.

When you actually become involved in this PR, you may notice that the developer became much more motivated. It is very dull to develop something, about which nobody cares

Indeed, that has been my experience in my day job too. I am more motivated if the users of our software ask/complain about features, functionalities.

EDIT: grammar.

1 Like

:yum: with tongue in cheek … just posted another “fuss” in that GPR. heh!

1 Like

Really? I tend to find those kinds of comments irritating and borderline insulting. Active useful involvement (e.g. helping to review things) is encouraging. Comments describing a specific use case you have for the feature, or an additional bug report that would be addressed by it, can be encouraging. Comments that just say “I want this. Can we get it in the next version?” or “When will this be ready?” just sound to me as “You’re not doing enough free work for me – I demand more of your free time so that this is finished sooner”

1 Like

With my tongue firmly out of cheek, it is best to not post such style of links from this forum to the OCaml bug tracker.

The PR referenced is complex and multiple years of effort. What would be most useful is to:

  • read through the last known status posted by the author and attempt to reproduce it. For example, does the Dockerfile that @kayceesrk posted still work with your intended use?
  • describe your desired usecase clearly, and make an effort to relate it to the last known status. For instance, what do you need “dynload debugging” for, and could you make do without it (e.g. by statically linking the program for development purposes).
  • Contributing some effort such as the above will help you earn the “we” in “if not could we prioritise this for 4.07 please”.

More generally, this discussion forum is intended as a distillation area for broad-sweeping discussions, from beginner learning to community efforts to design discussions for mutual learning amongst ourselves.

Once a conclusion has been reached regarding something that is concretely actionable in the core OCaml toolchain, it should be posted in a standalone way to the OCaml bug tracker, rather than links to this forum just posted verbatim. I did not intend this forum to become an area for “mob fuss” to add noise to complex language PRs, and would appreciate all of your help in maintaining this ethos and ensuring it remains a constructive force in the OCaml community.

7 Likes

I did try that docker-file and found it quite useful in my test program. I was then wondering if this would be in 4.07 which was what all this fuss was about. I do want to try/test the GPR. However, I believe the GPR currently has some merge conflicts + other dependent GPRs which hasn’t been merged into trunk yet. I definitely am not yet competent enough to resolve those conflicts and even less comment/review on the technical nature of the GPR.

My specific use case for ‘dynload debugging’ arose out of my attempt to resolve ‘ppx_deriving’ issues,


and

‘ppx_deriving’ uses ocaml dynload feature to load ‘deriving’ plugins. I tried in vain to use ocamldebug to trace through the program data/flow but gave up after a few late evenings. I then tried gdb after @jeremiedimino’s gentle and helpful instructions. But I found ocaml native debugging in gdb quite limited at the moment. No expression evaluation, no variable value printing, no go back and forth etc.

Thanks for the clarification. Noted!

1 Like

Indeed, I came to the same conclusion regarding ‘ppx_deriving’, i.e. linking the derivers statically together into one binary. However, that would probably be a risky, and big change to the codebase. The issue is closed now but I did post my findings to the issue.
https://github.com/ocaml-ppx/ppx_deriving/issues/153#issuecomment-339281938

1 Like