Eix (update-eix) is reading up to 50% and crashes. When debugging, it was comparing versions specified as "0" and "002". The following function is causing problems: eix::numeric_compare(), residing in eixTk/compare.h. The problem is here: const std::string::size_type lstart = left.find_first_not_of('0'); lstart becomes string::npos, when left == "0". Next, this value is used for default_compare(), where lstart is first checked for string::npos (and changed to 0 if so). However then it's used in the following instruction: return left.compare(lstart, std::string::npos, right, rstart, std::string::npos); where the possible string::npos values of lstart or rstart IS NOT PREVENTED AGAINST! Below is my proposal of how this function's code should look like: // strip leading 0's const std::string::size_type lstart = left.find_first_not_of('0'); const std::string::size_type rstart = right.find_first_not_of('0'); if ( lstart == std::string::npos ) lstart = 0; if ( rstart == std::string::npos ) rstart = 0; // check if one is longer, that one would be bigger const int size_result = default_compare(left.size() - lstart, right.size() - rstart); if (size_result) return size_result; // both strings have the same length, do string comparison return left.compare(lstart, std::string::npos, right, rstart, std::string::npos); Reproducible: Always Steps to Reproduce: 1. Run update-eix 2. See the crash message (unexpected exception std::out_of_range) Actual Results: Crash Expected Results: No crash May be irreproducible unless used with data that produce an exactly "0" number of version. You can try to feed eix with a fake data with a package having "0" version (which may be an error, but eix shouldn't crash on such a problem either!), or just believe in my analysis. :) I set this problem as major because it concerns one of the basic tools of Gentoo, while it's really easy to fix.
*** This bug has been marked as a duplicate of bug 238216 ***
I'm really sorry, but I couldn't find any other problem reported for Eix. :)
