Re: [lmi] _M_range_check fails when running "new" PDF

[Vadim Zeitlin]

On Tue, 13 Feb 2018 20:45:59 +0000 Greg Chicares <address@hidden> wrote:

GC> We see this message:
GC>   vector::_M_range_check: __n (which is 0) >= this->size() (which is 0)
GC> with ledger type mce_individual_private_placement when we run an
GC> "inforce" illustration. "Inforce" means, e.g., that you bought a
GC> life insurance policy in the past, and now you want an illustration
GC> that starts today (as opposed to starting when the policy was sold).

 Thanks for finding this bug, I could reproduce it easily, but couldn't see
where did the check fail exactly as gdb refused to "catch throw" or stop at
stl_vector.h:804, where this exception was thrown. I still have no idea how
exactly to debug standard library code under MinGW, but I could see the
same problem in the native Linux build of the program (where I had to fix a
couple of problems to be able to use configure again, hence my recent
changes to it and Makefile.am) and now I know what happens:

 The problem is due to "IrrCsv_GuaranteedZero" vector being empty in this
case, which is unexpected as the table generation code assumes that all the
values do always exist. A trivial fix for the problem would be to check
that the index is valid in ledger_evaluator::operator() and return an empty
string if it isn't, but I'm not really comfortable with doing this, as this
could easily hide genuine errors too.

 Another possibility would be to add a separate ledger_evaluator method
called get_if_exists_or_empty() or something shorter but with the same
connotation, that could be explicitly used when the caller expects that the
value might not be available. But while this is better than never checking
for the vector size at all, it's still potentially dangerous.

 So my preferred solution would be to fill IrrCsv_GuaranteedZero (and other
similar vectors) with zeroes when LedgerInvariant::IrrCsvGuar0 (and others)
is empty. What do you think of this proposal?

 Also, would you know of any other vectors used for table columns which
might not have the values for all (or any, as is the case here) years?


 Additionally, this underscores once again the need for better error
handling, I'll try to do something about this a.s.a.p.

 But in the meanwhile I'd like to fix this bug first, please let me know if
you have any thoughts about what would be the best way to do it.

 Thanks in advance!
VZ