-
Notifications
You must be signed in to change notification settings - Fork 78
Description
In the course of tracking down a bug in SLiM having to do with an uncaught (by SLiM) overflow of a tskit table (didn't check the pesky return value!), @molpopgen wrote a little snippet of debugging code, which I modified into this form:
std::size_t debug_edge_index = 0;
for( ; debug_edge_index < tables_.edges.num_rows ; ++debug_edge_index)
{
if ((tables_.edges.parent[debug_edge_index] >= tables_.nodes.num_rows) || (tables_.edges.parent[debug_edge_index] < 0))
{
std::cout << "parent index out of range: " << tables_.edges.parent[debug_edge_index] << ", " << tables_.nodes.num_rows << std::endl;
break;
}
if ((tables_.edges.child[debug_edge_index] >= tables_.nodes.num_rows) || (tables_.edges.child[debug_edge_index] < 0))
{
std::cout << "child index out of range: " << tables_.edges.child[debug_edge_index] << ", " << tables_.nodes.num_rows << std::endl;
break;
}
}
It caught the problem and provided the key information needed to track down the bug. It's not rocket science, obviously, but it got me to thinking that it would be useful for tskit to have a "consistency check" function that would check all sorts of things about a table collection: that all indices are within range, that things that ought to correspond with each other do correspond with each other, etc. That the table collection is, in every respect one can think of, well-formed. Client code like SLiM, fwdpp, etc., could call that check as often as desired to make sure that nothing untoward has occurred. I'll tag @petrelharp here as well since he was in the previous discussion / bug-hunt. :->