[Bug 1899414] [NEW] schroot fails for source chroots with 'std:bad_alloc' on groovy
Alex Murray
1899414 at bugs.launchpad.net
Mon Oct 12 05:15:26 UTC 2020
Public bug reported:
After upgrading to groovy or installing fresh from the beta, schroot
fails to enter a source: chroot with std:bad_alloc:
$ schroot -c source:bionic-amd64
E: std::bad_alloc
Running this with debugging symbols under gdb we get the following
backtrace:
amurray at slate:~$ gdb --ex='break std::bad_alloc::bad_alloc()' --ex=run --args schroot -c source:bionic-amd64
GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from schroot...
Reading symbols from /usr/lib/debug/.build-id/70/4469864df39ed3af1f8a23bd8d27adffeb8315.debug...
Catchpoint 1 (throw)
Function "std::bad_alloc::bad_alloc()" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (std::bad_alloc::bad_alloc()) pending.
Starting program: /usr/bin/schroot -c source:bionic-amd64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Catchpoint 1 (exception thrown), 0x00007fd231965762 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt full
#0 0x00007fd231965762 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#1 0x00007fd231959562 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#2 0x00005596c26b8a2f in __gnu_cxx::new_allocator<char>::allocate (this=0x7ffd3b189dd0, __n=34359738368) at /usr/include/c++/9/ext/new_allocator.h:102
No locals.
#3 std::allocator_traits<std::allocator<char> >::allocate (__a=..., __n=34359738368) at /usr/include/c++/9/bits/alloc_traits.h:444
No locals.
#4 std::_Vector_base<char, std::allocator<char> >::_M_allocate (this=0x7ffd3b189dd0, __n=34359738368) at /usr/include/c++/9/bits/stl_vector.h:343
No locals.
#5 std::vector<char, std::allocator<char> >::reserve (this=this at entry=0x7ffd3b189dd0, __n=__n at entry=34359738368) at /usr/include/c++/9/bits/vector.tcc:78
__old_size = 0
__tmp = <optimised out>
#6 0x00005596c26b5996 in sbuild::group::query_name (this=0x7ffd3b189db0, name=0x5596c2c558c0 "admin") at ./sbuild/sbuild-util.cc:770
size = 34359738368
error = <optimised out>
grp_result = 0x0
#7 0x00005596c26b5abf in sbuild::group::query_name (name=..., this=0x7ffd3b189db0) at /usr/include/c++/9/bits/basic_string.h:2300
No locals.
#8 sbuild::group::group (this=0x7ffd3b189db0, name=...) at ./sbuild/sbuild-util.cc:717
No locals.
#9 0x00005596c26a463f in sbuild::session::is_group_member (this=<optimised out>, groupname="admin") at ./sbuild/sbuild-session.cc:390
grp = {<group> = {gr_name = 0x7fd1b0416010 <error: Cannot access memory at address 0x7fd1b0416010>, gr_passwd = 0x7fd1b041601e <error: Cannot access memory at address 0x7fd1b041601e>, gr_gid = 138,
gr_mem = 0x7fd1b0416028}, buffer = std::vector of length 0, capacity 17179869184, valid = false}
group_member = <optimised out>
__PRETTY_FUNCTION__ = <optimised out>
#10 0x00005596c26a49eb in sbuild::session::get_chroot_membership (this=0x5596c2c329f0, chroot=..., in_users=@0x7ffd3b189e94: false, in_root_users=@0x7ffd3b189e95: false, in_groups=@0x7ffd3b189e96: false,
in_root_groups=@0x7ffd3b189e97: true) at ./sbuild/sbuild-session.cc:475
gp = "admin"
users = std::vector of length 0, capacity 0
root_users = <optimised out>
groups = <optimised out>
root_groups = std::vector of length 3, capacity 3 = {"root", "sbuild", "admin"}
upos = <optimised out>
rupos = <optimised out>
#11 0x00005596c26a4cd1 in sbuild::session::get_chroot_auth_status (this=0x5596c2c329f0, status=sbuild::auth::STATUS_NONE, chroot=...) at ./sbuild/sbuild-session.cc:496
in_users = false
in_root_users = false
in_groups = false
in_root_groups = true
#12 0x00005596c26a3ae1 in sbuild::session::get_auth_status (this=0x5596c2c329f0) at ./sbuild/sbuild-session.cc:554
cur = {alias = "source:bionic-amd64", chroot = std::shared_ptr<sbuild::chroot> (use count 4, weak count 1) = {get() = 0x5596c2c51b80}}
status = sbuild::auth::STATUS_NONE
__PRETTY_FUNCTION__ = <optimised out>
#13 0x00005596c26a3fba in sbuild::session::run (this=0x5596c2c329f0) at /usr/include/c++/9/bits/shared_ptr_base.h:1020
No locals.
#14 0x00005596c2731fb9 in schroot::main_base::run_impl (this=0x7ffd3b18a180) at /usr/include/c++/9/bits/shared_ptr_base.h:1020
__PRETTY_FUNCTION__ = "virtual int schroot::main_base::run_impl()"
sess_op = <optimised out>
#15 0x00005596c272b392 in schroot_base::main::run (this=0x7ffd3b18a180, argc=<optimised out>, argv=0x7ffd3b18a3a8) at ./bin/schroot-base/schroot-base-main.cc:107
status = <optimised out>
#16 0x00005596c269a2f0 in schroot_base::run<schroot::options, schroot::main> (argc=3, argv=0x7ffd3b18a3a8) at /usr/include/c++/9/bits/shared_ptr_base.h:1388
opts = std::shared_ptr<schroot::options_base> (use count 3, weak count 0) = {get() = 0x5596c2c2cce0}
kit = {<schroot::main_base> = {<schroot_base::main> = {_vptr.main = 0x5596c2778200 <vtable for schroot::main+16>, program_name = "schroot",
program_usage = "[OPTION…] [COMMAND] — run command or shell in a chroot", program_options = std::shared_ptr<schroot_base::options> (use count 3, weak count 0) = {get() = 0x5596c2c2cce0},
use_syslog = true}, options = std::shared_ptr<schroot::options_base> (use count 3, weak count 0) = {get() = 0x5596c2c2cce0}, config =
This shows sbuild is querying for the group 'admin' - however this does not exist on my groovy install:
amurray at slate:~$ getent group | grep ^admin
amurray at slate:~$
The reason it is checking for admin comes from the following 2
references for setting up schroot etc -
https://wiki.ubuntu.com/SimpleSbuild and
https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Creating_the_schroots
- these both suggest creating a ~/.mk-sbuild.rc with the following
entry:
SCHROOT_CONF_SUFFIX="source-root-users=root,sbuild,admin
source-root-groups=root,sbuild,admin
preserve-environment=true"
So in this case, sbuild will allow users in the root, sbuild or admin
groups to be root in the source schroot.
The actual failure seems to be because the sbuild code does not check
for appropriate errors from getpwnam_r / getpwuid_r - in sbuild-utilc.cc
there is 4 variants of code like:
while ((error = getgrnam_r(name, this,
&buffer[0], buffer.capacity(),
&grp_result)))
{
size <<= 1;
buffer.reserve(size);
}
However, this should only try and reallocate a larger buffer if these
return ERANGE. Otherwise, if it fails for some other reason (like the
group does not exist) it will continue to try and allocate a larger and
larger buffer until it fails due to lack of memory.
This would appear to be the same bug as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=763896 and whilst according to that bug it was
fixed in schroot git upstream, perhaps this never made it into a debian
and hence Ubuntu release?
** Affects: schroot (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to schroot in Ubuntu.
https://bugs.launchpad.net/bugs/1899414
Title:
schroot fails for source chroots with 'std:bad_alloc' on groovy
Status in schroot package in Ubuntu:
New
Bug description:
After upgrading to groovy or installing fresh from the beta, schroot
fails to enter a source: chroot with std:bad_alloc:
$ schroot -c source:bionic-amd64
E: std::bad_alloc
Running this with debugging symbols under gdb we get the following
backtrace:
amurray at slate:~$ gdb --ex='break std::bad_alloc::bad_alloc()' --ex=run --args schroot -c source:bionic-amd64
GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from schroot...
Reading symbols from /usr/lib/debug/.build-id/70/4469864df39ed3af1f8a23bd8d27adffeb8315.debug...
Catchpoint 1 (throw)
Function "std::bad_alloc::bad_alloc()" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (std::bad_alloc::bad_alloc()) pending.
Starting program: /usr/bin/schroot -c source:bionic-amd64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Catchpoint 1 (exception thrown), 0x00007fd231965762 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt full
#0 0x00007fd231965762 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#1 0x00007fd231959562 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#2 0x00005596c26b8a2f in __gnu_cxx::new_allocator<char>::allocate (this=0x7ffd3b189dd0, __n=34359738368) at /usr/include/c++/9/ext/new_allocator.h:102
No locals.
#3 std::allocator_traits<std::allocator<char> >::allocate (__a=..., __n=34359738368) at /usr/include/c++/9/bits/alloc_traits.h:444
No locals.
#4 std::_Vector_base<char, std::allocator<char> >::_M_allocate (this=0x7ffd3b189dd0, __n=34359738368) at /usr/include/c++/9/bits/stl_vector.h:343
No locals.
#5 std::vector<char, std::allocator<char> >::reserve (this=this at entry=0x7ffd3b189dd0, __n=__n at entry=34359738368) at /usr/include/c++/9/bits/vector.tcc:78
__old_size = 0
__tmp = <optimised out>
#6 0x00005596c26b5996 in sbuild::group::query_name (this=0x7ffd3b189db0, name=0x5596c2c558c0 "admin") at ./sbuild/sbuild-util.cc:770
size = 34359738368
error = <optimised out>
grp_result = 0x0
#7 0x00005596c26b5abf in sbuild::group::query_name (name=..., this=0x7ffd3b189db0) at /usr/include/c++/9/bits/basic_string.h:2300
No locals.
#8 sbuild::group::group (this=0x7ffd3b189db0, name=...) at ./sbuild/sbuild-util.cc:717
No locals.
#9 0x00005596c26a463f in sbuild::session::is_group_member (this=<optimised out>, groupname="admin") at ./sbuild/sbuild-session.cc:390
grp = {<group> = {gr_name = 0x7fd1b0416010 <error: Cannot access memory at address 0x7fd1b0416010>, gr_passwd = 0x7fd1b041601e <error: Cannot access memory at address 0x7fd1b041601e>, gr_gid = 138,
gr_mem = 0x7fd1b0416028}, buffer = std::vector of length 0, capacity 17179869184, valid = false}
group_member = <optimised out>
__PRETTY_FUNCTION__ = <optimised out>
#10 0x00005596c26a49eb in sbuild::session::get_chroot_membership (this=0x5596c2c329f0, chroot=..., in_users=@0x7ffd3b189e94: false, in_root_users=@0x7ffd3b189e95: false, in_groups=@0x7ffd3b189e96: false,
in_root_groups=@0x7ffd3b189e97: true) at ./sbuild/sbuild-session.cc:475
gp = "admin"
users = std::vector of length 0, capacity 0
root_users = <optimised out>
groups = <optimised out>
root_groups = std::vector of length 3, capacity 3 = {"root", "sbuild", "admin"}
upos = <optimised out>
rupos = <optimised out>
#11 0x00005596c26a4cd1 in sbuild::session::get_chroot_auth_status (this=0x5596c2c329f0, status=sbuild::auth::STATUS_NONE, chroot=...) at ./sbuild/sbuild-session.cc:496
in_users = false
in_root_users = false
in_groups = false
in_root_groups = true
#12 0x00005596c26a3ae1 in sbuild::session::get_auth_status (this=0x5596c2c329f0) at ./sbuild/sbuild-session.cc:554
cur = {alias = "source:bionic-amd64", chroot = std::shared_ptr<sbuild::chroot> (use count 4, weak count 1) = {get() = 0x5596c2c51b80}}
status = sbuild::auth::STATUS_NONE
__PRETTY_FUNCTION__ = <optimised out>
#13 0x00005596c26a3fba in sbuild::session::run (this=0x5596c2c329f0) at /usr/include/c++/9/bits/shared_ptr_base.h:1020
No locals.
#14 0x00005596c2731fb9 in schroot::main_base::run_impl (this=0x7ffd3b18a180) at /usr/include/c++/9/bits/shared_ptr_base.h:1020
__PRETTY_FUNCTION__ = "virtual int schroot::main_base::run_impl()"
sess_op = <optimised out>
#15 0x00005596c272b392 in schroot_base::main::run (this=0x7ffd3b18a180, argc=<optimised out>, argv=0x7ffd3b18a3a8) at ./bin/schroot-base/schroot-base-main.cc:107
status = <optimised out>
#16 0x00005596c269a2f0 in schroot_base::run<schroot::options, schroot::main> (argc=3, argv=0x7ffd3b18a3a8) at /usr/include/c++/9/bits/shared_ptr_base.h:1388
opts = std::shared_ptr<schroot::options_base> (use count 3, weak count 0) = {get() = 0x5596c2c2cce0}
kit = {<schroot::main_base> = {<schroot_base::main> = {_vptr.main = 0x5596c2778200 <vtable for schroot::main+16>, program_name = "schroot",
program_usage = "[OPTION…] [COMMAND] — run command or shell in a chroot", program_options = std::shared_ptr<schroot_base::options> (use count 3, weak count 0) = {get() = 0x5596c2c2cce0},
use_syslog = true}, options = std::shared_ptr<schroot::options_base> (use count 3, weak count 0) = {get() = 0x5596c2c2cce0}, config =
This shows sbuild is querying for the group 'admin' - however this does not exist on my groovy install:
amurray at slate:~$ getent group | grep ^admin
amurray at slate:~$
The reason it is checking for admin comes from the following 2
references for setting up schroot etc -
https://wiki.ubuntu.com/SimpleSbuild and
https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Creating_the_schroots
- these both suggest creating a ~/.mk-sbuild.rc with the following
entry:
SCHROOT_CONF_SUFFIX="source-root-users=root,sbuild,admin
source-root-groups=root,sbuild,admin
preserve-environment=true"
So in this case, sbuild will allow users in the root, sbuild or admin
groups to be root in the source schroot.
The actual failure seems to be because the sbuild code does not check
for appropriate errors from getpwnam_r / getpwuid_r - in sbuild-
utilc.cc there is 4 variants of code like:
while ((error = getgrnam_r(name, this,
&buffer[0], buffer.capacity(),
&grp_result)))
{
size <<= 1;
buffer.reserve(size);
}
However, this should only try and reallocate a larger buffer if these
return ERANGE. Otherwise, if it fails for some other reason (like the
group does not exist) it will continue to try and allocate a larger
and larger buffer until it fails due to lack of memory.
This would appear to be the same bug as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=763896 and whilst according to that bug it was
fixed in schroot git upstream, perhaps this never made it into a
debian and hence Ubuntu release?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1899414/+subscriptions
More information about the foundations-bugs
mailing list