There have been cases in the past where changes, particularly in Stack Exchange, result in SD continuously crashing. The current logic in nocrash.py is that we start reverting back through the commit history in order to find a commit which doesn't crash. That's a good strategy, if the problem is a broken change we've made to SD and SD just needs to get back to a commit that doesn't have the broken changes.
However, in some fault cases, such a prior commit might not exist (or might be hundreds or thousands of commits in the past). In such cases, the only effective solution is new code. So, when nocrash.py is in its revert loop, it should also check to see if there is new code. If there's new code that qualifies (i.e., has passed CI), then it should pull that code and try it. If that code still crashes, nocrash.py should return to the revert process where it left off. This should be repeated, if there's yet more new code.
There have been cases in the past where changes, particularly in Stack Exchange, result in SD continuously crashing. The current logic in nocrash.py is that we start reverting back through the commit history in order to find a commit which doesn't crash. That's a good strategy, if the problem is a broken change we've made to SD and SD just needs to get back to a commit that doesn't have the broken changes.
However, in some fault cases, such a prior commit might not exist (or might be hundreds or thousands of commits in the past). In such cases, the only effective solution is new code. So, when nocrash.py is in its revert loop, it should also check to see if there is new code. If there's new code that qualifies (i.e., has passed CI), then it should pull that code and try it. If that code still crashes, nocrash.py should return to the revert process where it left off. This should be repeated, if there's yet more new code.