Analysis: Gnats 5623: Running CRSS and hitting an error gives many new assertion messages [3-19-2015].
See Recommendation below. Minor edits: 3-21-2015.
Internal gnats link; See also the "Bug5623" git branch.

After an MRM run fails due to an incompatable RPL Set version number ...

... click thumbnail to see error ...

... a MrmDmi::FileInfo object's Date_Time _startDt is not given a value. Its absolute seconds is zero (0).

A subsequent call to the RunParam MrmDmi::FileInfo::getRunParam() method (see following) performs an invalid subtraction with that zero-value Date_Time. This method constructs and returns a RunParam value. In the course of doing that (in this case), it attempts to subtract "one month of seconds" from the zero-value Date_Time. See this annotated code ...

The change above avoids the reported problem -- myriad assertion failures in seconds_t Date_Time::monthSeconds (int absm).

Note that _monthSecondsArray in the code above is a dynamically allocated C++ array of seconds_t (64-bit integers). It isn't a higher level QVector. So dereferencing this array with a negative index is a generally quiet, unchecked disaster.

The failure of the assertion which was introduced in January (see above) is important. The recovery added to that initial assertion failure clause will result in at least a valid number of seconds for a month. (Before that, we were just indexing off into garbage, returning god-knows-what number of seconds. Much worse). All of the relevant related Date_Time code assumes that invalid data (in this case, a negative month index) will not be presented to the Date_Time class. An assertion is appropriate and necessary, as the workaround doesn't necessarily return the right number of seconds for the intended month.

But I would like to "throttle" the issuing of that assertion, given that if it does ever happen, it may happen myriad times -- as was the case with this bug (5623).

Recommendation

I would like to do the following:

1. Modify the Date_Time::monthSeconds() assertion to be tested only if it hasn't yet failed since the last Run Start or Clear Model.
2. Use the getRunParam() modification shown above. Since the special handling of a zero _startDt is engaged only after a run abort, it is not necessary to report this low-level error; in such a case, the recovery is sufficient (because the run has, in fact, already aborted).

But I could imagine alternatives to this proposal, e.g. tracking down the higher level code which allows this MrmDmi::FileInfo instance to have a zero _startDt value after a run abort. (But I don't think that's actually necessary, for a reason related to what was stated in item #2 above).

---