You are not logged in.
After recently upgrading schroot to 1.6.10-29, I can't enter any schroot:
$ schroot
/usr/include/c++/11.1.0/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = char; _Alloc = std::allocator<char>; std::vector<_Tp, _Alloc>::reference = char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Aborted (core dumped)After downloading the package source with abs and running makepkg -sri, it all works well. Also noticed that the schroot binary size is 847008 from the repo but 1090864 when built locally.
What could be causing this?
Last edited by pumaking (2022-01-26 09:52:56)
Offline
I wonder how you have been able to solve this by just doing a rebuild from the source package. The problem is that in sbuild-util.cc they try to read the address of a std::vector<char> by &buffer[0] though buffer[0] has never been set. There is a call to buffer.reserve() first but as this only allocates the required memory but does not change buffer.size() the assertion correctly points to an illegal access to element 0. Looks as if the assertion checks have been enabled lately. I am not sure. I was able to fix this with the patch
--- sbuild-util.cc.orig 2022-01-23 19:52:13.409893287 +0100
+++ sbuild-util.cc 2022-01-23 19:44:01.167309089 +0100
@@ -627,6 +627,7 @@
{
buffer_type::size_type size = 1 << 7;
buffer.reserve(size);
+ buffer.push_back(0);
int error;
::passwd *pwd_result;
@@ -650,6 +651,7 @@
{
buffer_type::size_type size = 1 << 8;
buffer.reserve(size);
+ buffer.push_back(0);
int error;
::passwd *pwd_result;
@@ -736,6 +738,7 @@
{
buffer_type::size_type size = 1 << 7;
buffer.reserve(size);
+ buffer.push_back(0);
int error;
::group *grp_result;
@@ -759,6 +762,7 @@
{
buffer_type::size_type size = 1 << 8;
buffer.reserve(size);
+ buffer.push_back(0);
int error;
::group *grp_result;
which is just an ugly hack but does the trick.
Offline
A much simpler fix is this:
--- sbuild-util.cc.orig 2022-01-23 19:52:13.409893287 +0100
+++ sbuild-util.cc 2022-01-23 20:06:49.073783841 +0100
@@ -612,6 +612,7 @@
valid = false;
buffer.clear();
+ buffer.push_back(0);
::passwd::pw_name = 0;
::passwd::pw_passwd = 0;
@@ -724,6 +725,7 @@
valid = false;
buffer.clear();
+ buffer.push_back(0);
::group::gr_name = 0;
::group::gr_passwd = 0;
Offline
I think Fedora fixed it using https://src.fedoraproject.org/rpms/schr … -fix.patch
Offline
I wonder how you have been able to solve this by just doing a rebuild from the source package.
I'm not sure. I did a clean makepkg -sri and it still works after a local build. Maybe a different compiler version. Is there a way to check in what environment a package in the official repos was built?
I've created a bug for this: https://bugs.archlinux.org/task/73481.
Offline
What is the CXXFLAGS set to on your system?
As the official package was built using devtools recorded in .BUILDINFO in the package archive it was probably built using
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"Last edited by loqs (2022-01-23 22:07:26)
Offline
Ah I didn't have any CXXFLAGS set so it's probably a flag difference. I tried re-compiling after
both
export CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"and
export CFLAGS="-march=x86-64 -mtune=genreic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS -Werror=format-security -fstack-clash-protection -fcf-protection"
export CXXFLAGS="$CFLAGS"and was not able to reproduce the issue but I must've done something wrong.
Offline
I think Fedora fixed it using https://src.fedoraproject.org/rpms/schr … -fix.patch
Yes, that one is much better than mine. I took a quick lookup for something like data() but I missed it. Anyway, that proves the solution is correct and solves the issue.
Offline