Comment 1 for bug 1899414

Revision history for this message
Roger Leigh (rleigh) wrote : RE: [Bug 1899414] [NEW] schroot fails for source chroots with 'std:bad_alloc' on groovy

Hi Alex,This is failing here:https://gitlab.com/codelibre/schroot/-/blob/schroot-1.6/sbuild/sbuild-util.cc#L757Is there something unusual about the group being checked?  getgrnam_r has returned ERANGE and schroot increased the buffer size to accommodate this until it ran out of memory.  The cause of failure is clear but the reason is not.Are you using LDAP, AD or is this all local users and groups?Kind regards,Roger Leigh
-------- Original message --------From: Alex Murray <email address hidden> Date: 12/10/2020 06:20 (GMT+00:00) To: <email address hidden> Subject: [Bug 1899414] [NEW] schroot fails for source chroots with
  'std:bad_alloc' on groovy Public bug reported:After upgrading to groovy or installing fresh from the beta, schrootfails to enter a source: chroot with std:bad_alloc:$ schroot -c source:bionic-amd64E: std::bad_allocRunning this with debugging symbols under gdb we get the followingbacktrace:amurray@slate:~$ gdb --ex='break std::bad_alloc::bad_alloc()' --ex=run --args schroot -c source:bionic-amd64GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2Copyright (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]) yBreakpoint 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.6No symbol table info available.#1  0x00007fd231959562 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6No 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:102No locals.#3  std::allocator_traits<std::allocator<char> >::allocate (__a=..., __n=34359738368) at /usr/include/c++/9/bits/alloc_traits.h:444No locals.#4  std::_Vector_base<char, std::allocator<char> >::_M_allocate (this=0x7ffd3b189dd0, __n=34359738368) at /usr/include/c++/9/bits/stl_vector.h:343No 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:2300No locals.#8  sbuild::group::group (this=0x7ffd3b189db0, name=...) at ./sbuild/sbuild-util.cc:717No 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:1020No 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 ^adminamurray@slate:~$ The reason it is checking for admin comes from the following 2references for setting up schroot etc -https://wiki.ubuntu.com/SimpleSbuild andhttps://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Creating_the_schroots- these both suggest creating a ~/.mk-sbuild.rc with the followingentry:SCHROOT_CONF_SUFFIX="source-root-users=root,sbuild,adminsource-root-groups=root,sbuild,adminpreserve-environment=true"So in this case, sbuild will allow users in the root, sbuild or admingroups to be root in the source schroot.The actual failure seems to be because the sbuild code does not checkfor appropriate errors from getpwnam_r / getpwuid_r - in sbuild-utilc.ccthere 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 thesereturn ERANGE. Otherwise, if it fails for some other reason (like thegroup does not exist) it will continue to try and allocate a larger andlarger 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 wasfixed in schroot git upstream, perhaps this never made it into a debianand hence Ubuntu release?** Affects: schroot (Ubuntu)     Importance: Undecided         Status: New-- You received this bug notification because you are subscribed to schrootin Ubuntu.https://bugs.launchpad.net/bugs/1899414Title:  schroot fails for source chroots with 'std:bad_alloc' on groovyTo manage notifications about this bug go to:https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1899414/+subscriptions