[ OK ] Deserializer.IntegerVectorFailOnReadElements (0 ms) [ RUN ] Deserializer.NonIntegerVectorFailOnReadElement [ OK ] Deserializer.NonIntegerVectorFailOnReadElement (0 ms) [ RUN ] Deserializer.Vector /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; reference = unsigned char&; size_type = long unsigned int]: Assertion '__n < this->size()' failed. /var/tmp/portage/dev-libs/libnop-2021.11.03/temp/environment: line 626: 23 Aborted out/test * ERROR: dev-libs/libnop-2021.11.03::gentoo failed (test phase): * (no error message) * ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no_multilib_hardened_test-20231010-123509 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10 [2] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 17.0.2 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/17/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/17 17.0.2 Python 3.11.6 Available Rust versions: [1] rust-bin-1.73.0 * The following VMs are available for generation-2: 1) OpenJDK 17.0.8.1_p1 [openjdk-17] 2) OpenJDK 8.382_p05 [openjdk-8] *) Eclipse Temurin JDK 17.0.8.1_p1 [openjdk-bin-17] 4) Eclipse Temurin JDK 8.382_p05 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-8 [2] openjdk-17 [3] openjdk-bin-8 [4] openjdk-bin-17 system-vm php cli (if any): go version go1.21.1 linux/amd64 HEAD of ::gentoo commit 768aede446ff639edd47ed8b67d6e0320afe6357 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sun Oct 15 11:48:14 2023 +0000 2023-10-15 11:48:14 UTC emerge -qpvO dev-libs/libnop [ebuild N ] dev-libs/libnop-2021.11.03 USE="test"
Created attachment 872905 [details] emerge-info.txt
Created attachment 872906 [details] dev-libs:libnop-2021.11.03:20231015-122340.log
Created attachment 872907 [details] emerge-history.txt
Created attachment 872908 [details] environment
Created attachment 872909 [details] etc.clang.tar.xz
Created attachment 872910 [details] etc.portage.tar.xz
Created attachment 872911 [details] qlist-info.txt.xz
Created attachment 872912 [details] temp.tar.xz
tracked down to -> std::copy(&data_[index_], &data_[index_ + length_bytes], begin_byte); where data_[index_ + length_bytes] is accessing the last + 1 element but std::copy does not access it, it does copy [low..up) Can this be closed ?
op[] is expressed in terms of *(begin() + idx): https://eel.is/c++draft/sequence.reqmts#119 dereferencing the end iterator is invalid. with that context: (gdb) p data_ $10 = std::vector of length 6, capacity 8 = {188 '\274', 4 '\004', 1 '\001', 2 '\002', 3 '\003', 4 '\004'} (gdb) p index_ + length_bytes $11 = 6 (gdb) this means that end() is dereferenced through op[]. the code ought to do std::copy(data_.begin() + index, data_.begin() + index_ + length_bytes, begin_byte) (that also ought to be formatted better.. auto start = data_begin() + index; and use start instead)
(In reply to Arsen Arsenović from comment #10) > op[] is expressed in terms of *(begin() + idx): > https://eel.is/c++draft/sequence.reqmts#119 > > dereferencing the end iterator is invalid. I cannot say I am a c++ expert but that std:copy is equivalent to std::copy(&data_[index_], &data_.end(), begin_byte) std::copy does not dereference the 2nd parameter. I don't see why should I fix it. I know that something like std::copy(&data_[index_], &data_[index_ + length_bytes - 1] + 1, begin_byte); can work to overcome the assert but that is just a trick
(In reply to Tupone Alfredo from comment #11) > I cannot say I am a c++ expert but I am though. > that std:copy is equivalent to > > std::copy(&data_[index_], &data_.end(), begin_byte) Well that won't even compile. If you mean &*data_.end() then yes, it is equivalent to that, and that's also invalid. The past-the-end iterator returned by data_.end() is not dereferenceable, so *data_.end() has undefined behaviour. > std::copy does not dereference the 2nd parameter. That's true, but the problem is not inside std::copy. The problem occurs before you even call std::copy where you access a non-existent element after the end of the container and then try to take its address. You cannot take the address of an object that doesn't exist. It's valid to add one to the address of the last object, to get a past-the-end pointer. It's not valid to access after the last object and take its address. int arr[2]; int* end = arr + 2; // OK int* bad = &arr[2]; // undefined > I don't see why should I > fix it. Because it's not valid C++. The assertion is correct, and your code is not. If you don't care to write valid C++ that's your choice, but this is your bug, not gentoo's.
I applied this patch --- a/test/test_reader.h 2023-11-14 22:21:10.528641740 +0100 +++ b/test/test_reader.h 2023-11-14 22:21:23.195431970 +0100 @@ -57,7 +57,7 @@ if (length_bytes > (data_.size() - index_)) return ErrorStatus::ReadLimitReached; - std::copy(&data_[index_], &data_[index_ + length_bytes], begin_byte); + std::copy(&data_[index_], &data_[index_] + length_bytes, begin_byte); index_ += length_bytes; return {}; } I wrongly closed the parent's bug. Reopened
commit d7c0d71054fd98e8105ccf7a6173aa6e42bff146 Author: Alfredo Tupone <tupone@gentoo.org> Date: Tue Nov 14 22:26:52 2023 +0100 dev-libs/libnop: Failures with -D_GLIBCXX_ASSERTIONS Closes: https://bugs.gentoo.org/884417 Signed-off-by: Alfredo Tupone <tupone@gentoo.org> i.e. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d7c0d71054fd98e8105ccf7a6173aa6e42bff146
