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@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@entry=0x7ffd3b189dd0, __n=__n@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@slate:~$ getent group | grep ^admin amurray@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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899414 Title: schroot fails for source chroots with 'std:bad_alloc' on groovy To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1899414/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
