new CI builds

Berthold Stoeger bstoeger at mail.tuwien.ac.at
Tue Apr 21 00:20:46 PDT 2020


Ok, this one is weird.

On Dienstag, 21. April 2020 08:44:09 CEST Chirana Gheorghita Eugeniu Theodor 
wrote:

> /usr/include/c++/9/bits/stl_vector.h:1042: std::vector<_Tp,
> _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp,
> _Alloc>::size_type) [with _Tp = int; _Alloc = std::allocator<int>;
> std::vector<_Tp, _Alloc>::reference = int&; std::vector<_Tp,
> _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n <
> this->size(), true)' failed.

That appears to be g++, right? To me this looks like it trips on an assertion 
of a "vector[n]" access. The one thing I found in the offending function was a 
construct of the type
  "&mean[0]"
to pass an array down to C, which *technically* is indeed undefined behavior 
if "mean" is empty. However, the whole point of operator[] is that it is 
unchecked and as long as the callee doesn't access the array, this should work 
just fine. After all it is only taking an address.

Therefore, I replaced above construct by "mean.data()" and put the call in an 
if for good measure:
  https://github.com/Subsurface-divelog/subsurface/pull/2778
Please test this.

If my suspicion is correct, I consider that very unfriendly behavior of the 
compiler / library. @Dirk: does that version compile with other than the 
default settings?

Berthold





More information about the subsurface mailing list