Closed ShyamieG closed 9 months ago
I can confirm this happens with commit 18e37aea, the last commit before the tskit update (as well as the commit after). gdb suggests it happens in TallyMutationRunReferencesForPopulation
.
I can also confirm that there's no segfault with v4.0. In trying to bisect the bug I'm running into problems - for some reason, I can't compile SLiM at a bunch of the intermediate commits (including v4.0.1, oddly).
ps. nice job pushing the boundaries of SLiM, @ShyamieG =)
Hi @petrelharp and @ShyamieG! Sorry for the slow response; I was having a little downtime after getting SLiM 4.1 out the door. :->
Sometimes I break the build for a little while, usually unintentionally – things build on my machine, but have an error on GitHub Actions. (I know, I should always work with PRs and squash and so forth, to avoid this. :->) So, sorry for the difficulties bisecting, @petrelharp – thanks for trying. The bisect would show that the bug came in at the point where I re-architected the way that mutation frequencies are tallied under the hood. That rearchitecture does not look like it introduced a bug, but it exposed a previously dormant bug elsewhere in the code – so even if you got it to bisect, the bug is not actually in those diffs, it's a pre-existing bug probably dating back quite a while in a totally different part of the code. :->
The problem is with SLiM's tracking of which subpopulations contain null genomes (as used in haploids for example, as placeholders for the "missing" genome). In this model, addRecombinant()
is used to generate haploids, with null genomes, into p7, and p7 is correctly marked as containing null genomes (which turns off certain optimizations, since things are more complicated with null genomes present – you have to check for them and handle them differently). So far so good. But then one of those haploids is cloned, with addCloned()
, into p8, and p8 is not correctly marked as then containing null genomes. The new mutation frequency tallying code uses that flag for some optimizations, and says "aha, no null genomes, here we go!" and then promptly crashes because, hey, null genomes. :-> The nice thing about this class of bugs is that they always produce a hard crash, so they're easy to get in the debugger. Back in SLiM 4.0.1, the mutation tallying code didn't rely on that flag, and so it noticed the null genomes and handled them gracefully – bug masked.
So, I know what the bug is, I just need to fix it. I'll post again here when I've done so. :->
@elissasoroj This bug might bite shadie. If it does, then I will need to do a 4.1.1 release, since we need shadie to work. :-> Please let me know at your earliest convenience – just run a variety of shadie test models for your different mating systems, and if none of them crash, then shadie is fine. The bug would be a 100% reproducible hard crash. Thanks!
(If the bug doesn't bite shadie then it might not bite many models at all – you might be the only one, @ShyamieG. In that case, I might just ask you to build SLiM from sources to get the bug fix, since I don't really want to roll 4.1.1 right now.)
Ha, it's not addCloned()
putting the null genomes in p8, it's takeMigrants()
. Sneaky. The bug was also present in addCloned()
, but that does not appear to be biting this model, or at least it isn't the first crash we hit. :-> But since the bug is present in addCloned()
too, I remain concerned about shadie. Anyhow, with the fixes to both methods in place, the model runs to completion without problems. I want to do some additional testing and checking before I commit this fix, though. I should have the fix in on Monday.
Thank you so much! I'll look out for the official fix next week.
Hi @ShyamieG! The fix is now pushed to GitHub. Please let me know if you encounter any further problems. Thanks for the very helpful bug report!
Hello @bhaller
I recently updated to SLiM 4.1 to address the issue I was having here. Unfortunately, I wasn't able to see if that issue was resolved by the update because it is failing at an earlier point with a segmentation fault.
My script starts with a tree sequence file and goes through 5 cycles before failing. Please see attached for my input files and slim script, and below for the bash code:
The output:
This step still runs just fine using slim 4.0.1 and produces the expected output. Any idea what could be going on? Thanks for your help!