On Sun, 14 Feb 2021 21:29:20 +0100 Andreas Beckmann <a...@debian.org> wrote:
Version: 1:5.2+dfsg-3~bpo10+1
On 2/14/21 4:46 PM, Michael Tokarev wrote:
> Before I was able to hit this issue with almost any invocation of aptitude.
> But in 5.0 or current 5.2 I can't reproduce this issue anymore, now matter
> how I try.
a simple 'aptitude -u' does the job for me :-(
The core file I get inside the chroot is actually from the qemu binary on the
host,
perhaps this backtrace helps:
Reading symbols from /usr/bin/qemu-aarch64-static...Reading symbols from
/usr/lib/debug/.build-id/30/efd3930fb9519b21470b113679376f2ffbb41a.debug...done.
done.
warning: core file may not match specified executable file.
[New LWP 23784]
[New LWP 23772]
[New LWP 23774]
[New LWP 23777]
[New LWP 23776]
[New LWP 23775]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/qemu-aarch64-static /usr/bin/aptitude -u'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000059a1eb in getgroups (__list=0x7f867be79cc0, __size=65536) at
/usr/include/x86_64-linux-gnu/bits/unistd.h:275
This comes from the following code, linux-user/syscall.c:11757 in qemu version
7.2:
case TARGET_NR_getgroups32:
{
int gidsetsize = arg1;
uint32_t *target_grouplist;
gid_t *grouplist;
int i;
grouplist = alloca(gidsetsize * sizeof(gid_t));
11757 ret = get_errno(getgroups(gidsetsize, grouplist));
gidsetsize as coming from aptitude is 65536. Grouplist is allocated on the
stack...
/mjt
