Add an error-raising function inside tskit?

[bhaller]

Hi! Asked this to Ben J. on Slack, and he suggested I open a Discussion, so here I am. :->

It can be a bit difficult to tell where exactly a problem is happening inside the tskit code. For example, I’m getting a TSK_ERR_BAD_PARAM_VALUE from somewhere inside a call to tsk_treeseq_init(), and I have no idea where/why. Finding the place where ret = TSK_ERR_BAD_PARAM_VALUE is actually happening more or less requires single-stepping through the code, I guess; there’s no way to set a breakpoint. It seems like it would be straightforward for you guys to replace the ret = X; goto out; pattern with an error-creating function that would set some additional error info, using LINE and FILE, which I think are standard in base C. Then it would be easy to report the line/file where the bad ret value got set, which would make life much easier; and even better, one could also set a breakpoint on that error-creating function and stop in the debugger at the point where the error is occurring. Has this sort of thing been considered? Would it be useful for me to file an issue on this? It would touch many lines of code, of course, but in a trivial way; and it shouldn’t affect execution speed at all, since the extra code complexity would only be hit when an error occurs. (I guess it’d increase the code size somewhat, and so maybe less code would fit in-cache, but it seems unlikely that it would matter much.)

[bhaller]

Ben J. replied:

What editor are you using? At least in VSCode I can set a breakpoint that fires if a line matches a regex.

You could also do a GDB command file with something like:

rbreak .
commands
silent
if $_return == ERR_CODE
  printf "Function %s returned ERR_CODE\n", $_function
  bt
else
  continue
end
end

(untested!)

This will break on any function that returns ERR_CODE

[bhaller]

I'm generally in Xcode, but occasionally in Qt Creator. Xcode uses lldb as its debugger; maybe it has a feature like this, but not to my knowledge. I have no idea what debugger Qt Creator uses, but it sucks tremendously so I avoid using it if at all possible. :-> In any case, it would be much easier and far more obvious if people could just set a breakpoint on a function like tsk_return_error() or some such. Is there any downside to doing that, as I discuss in my original question? Having a bottleneck for this is pretty standard practice, precisely because it does make setting a breakpoint much easier, across all debuggers/platforms.

[jeromekelleher]

Congratulations on a successful nerd-snipe @bhaller, I felt compelled to figure out a way to do this. I've a proposal in #3095.

I wish I'd thought of this years ago, as tracing down the exact location of errors during development is a major time sink!

[bhaller]

Your proposal looks great to me. A good error message built in, and also a bottleneck function that I can easily set a breakpoint on. I'd say go for it! :->