mmottl / gsl-ocaml

OCaml bindings to the GSL (GNU Scientific Library).
Other
36 stars 10 forks source link

debugging inside ocaml callback functions #28

Closed nilsbecker closed 6 years ago

nilsbecker commented 6 years ago

i am having a problem where an ocaml function being integrated via Gsl.Monte.integrate produces NaNs, spoiling the integration results. i don't know how to debug this since i cannot raise exceptions from within the callback function. is there a way to somehow get a backtrace of the inner function?

obviously i could evaluate the integrand separately; but the failures occur very rarely and happen inconsistently even when switching between machines, so it's hard to reproduce them.

mmottl commented 6 years ago

I'm not sure I understand the problem. Obviously, you can check for NANs yourself in the callback. If anything bad happens in your function, you can print debug information, which is usually sufficient. Exceptions should also be supported and could be used to pass information to the code calling the integrate function. If you do need a stack backtrace within a callback, you can also try out the Backtrace module in the Jane Street Core library.

nilsbecker commented 6 years ago

sorry for the noise. i think i misunderstood the cause of my problem. i was convinced that my function raised an exception and i could not see it, nor any printed output.

the 'error handling' paragraph of the readme file then seemed to suggest that exceptions are somehow lost inside of callbacks, and i attributed the missing exception to that. i now tried again to raise an exception somewhere else within the callback, which worked. it seems that the code path i thought of before was actually not taken.

in hindsight i seem to have misunderstood the readme file. which exceptions are not propagated?

mmottl commented 6 years ago

I think the comment only applies to some functions that take callbacks. It may not be a good idea to raise exceptions from callbacks, because some GSL-functions might call malloc internally and then leak memory. I guess not all wrappers intercept exceptions, but I don't have the time to investigate this. A lot of this code is very old and wasn't written by me.

nilsbecker commented 6 years ago

i see, thanks. so the current state of affairs is, "don't use exceptions for control flow inside callbacks, but maybe for debugging it's ok. no guarantees."

mmottl commented 6 years ago

The bindings should, of course, treat exceptions correctly. But I have never code reviewed all locations and would avoid exceptions for control flow.