Public bug reported:
Running aptitude in a lucid-based chroot qemu-arm-static on top of
amd64/oneiric segfaults/hangs. I get the segfault output about 30% of
the time, the rest of the time the problem exhibits as a hang. The
same commands work fine on a real armel platform (armv7l) running the
same package versions as the chroot.
Every command I have tried exhibits this behavior except for:
aptitude help
aptitude moo
Two simple commands that exhibit this behavior are:
aptitude show totem
aptitude hold
aptitude (no args to launch GUI)
Here is an example of the output:
root@caprica:/# aptitude show totem
Segmentation fault (core dumped)
root@caprica:/# aptitude show totem
<hangs here>
^C
root@caprica:/# aptitude show totem
Segmentation fault (core dumped)
root@caprica:/# aptitude show totem
<hangs here>
^C
root@caprica:/# aptitude show totem
<hangs here>
^C
root@caprica:/# aptitude show totem
Segmentation fault (core dumped)
Through printf debugging, I have traced the issue to the following area (if
you're looking at the case of "aptitude show totem" command). Basically, we
never make it into many of these cmdline_xxxx calls. I suspect the stack might
be corrupt, but cannot verify that:
Code snippet:
aptitude/src/main.cc:
else if(!strcasecmp(argv[optind], "show")) {
printf("we get here");
return cmdline_show(argc-optind, argv+optind, verbose);
}
aptitude/src/cmdline/cmdline_show.cc:
int cmdline_show(int argc, char *argv[], int verbose)
{
printf("We never get here!");
_error->DumpErrors();
...
-------------------------------------------------------------------------------------------------------------------------------------
Versions:
chroot guest:
root@caprica:/# uname -a
Linux caprica 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011
armv7l GNU/Linux
root@caprica:/# apt-cache policy aptitude
aptitude:
Installed: 0.4.11.11-1ubuntu10
Candidate: 0.4.11.11-1ubuntu10
Version table:
*** 0.4.11.11-1ubuntu10 0
500 http://ports.ubuntu.com/ubuntu-ports/ lucid/main Packages
100 /var/lib/dpkg/status
Host:
mfisch@caprica:~/Projects/charlotte-armel$ uname -a
Linux caprica 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
mfisch@caprica:~/Projects/charlotte-armel$ apt-cache policy qemu
qemu:
Installed: (none)
Candidate: 0.14.1+noroms-0ubuntu6
Version table:
0.14.1+noroms-0ubuntu6 0
500 http://us.archive.ubuntu.com/ubuntu/ oneiric/universe amd64 Packages
-------------------------------------------------------------------------------------------------------------------------------------
Things I've tried:
I have been unable to get any useful info via gdb, local or remote.
I have been unable to reproduce this using a stripped down copy of main.
The core file I generated was deemed unusable by gdb.
I do not have a syslog inside the chroot (it was suggested that I post the
syslog from the guest).
There is nothing in the host's syslog to indicate that the OOM killer was
running.
I am attaching two stack traces for two different commands. In both of
those cases the problem exhibited as a hang.
I realize that this bug might lack some details/debugging info that you
need, so if you need more details or need me to test anything, please
contact me on IRC or via email.
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/898474
Title:
aptitude in a lucid-based qemu-arm-static chroot segfaults/hangs, but
works on real h/w
Status in QEMU:
New
Bug description:
Running aptitude in a lucid-based chroot qemu-arm-static on top of
amd64/oneiric segfaults/hangs. I get the segfault output about 30%
of the time, the rest of the time the problem exhibits as a hang.
The same commands work fine on a real armel platform (armv7l) running
the same package versions as the chroot.
Every command I have tried exhibits this behavior except for:
aptitude help
aptitude moo
Two simple commands that exhibit this behavior are:
aptitude show totem
aptitude hold
aptitude (no args to launch GUI)
Here is an example of the output:
root@caprica:/# aptitude show totem
Segmentation fault (core dumped)
root@caprica:/# aptitude show totem
<hangs here>
^C
root@caprica:/# aptitude show totem
Segmentation fault (core dumped)
root@caprica:/# aptitude show totem
<hangs here>
^C
root@caprica:/# aptitude show totem
<hangs here>
^C
root@caprica:/# aptitude show totem
Segmentation fault (core dumped)
Through printf debugging, I have traced the issue to the following area (if
you're looking at the case of "aptitude show totem" command). Basically, we
never make it into many of these cmdline_xxxx calls. I suspect the stack might
be corrupt, but cannot verify that:
Code snippet:
aptitude/src/main.cc:
else if(!strcasecmp(argv[optind], "show")) {
printf("we get here");
return cmdline_show(argc-optind, argv+optind, verbose);
}
aptitude/src/cmdline/cmdline_show.cc:
int cmdline_show(int argc, char *argv[], int verbose)
{
printf("We never get here!");
_error->DumpErrors();
...
-------------------------------------------------------------------------------------------------------------------------------------
Versions:
chroot guest:
root@caprica:/# uname -a
Linux caprica 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011
armv7l GNU/Linux
root@caprica:/# apt-cache policy aptitude
aptitude:
Installed: 0.4.11.11-1ubuntu10
Candidate: 0.4.11.11-1ubuntu10
Version table:
*** 0.4.11.11-1ubuntu10 0
500 http://ports.ubuntu.com/ubuntu-ports/ lucid/main Packages
100 /var/lib/dpkg/status
Host:
mfisch@caprica:~/Projects/charlotte-armel$ uname -a
Linux caprica 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
mfisch@caprica:~/Projects/charlotte-armel$ apt-cache policy qemu
qemu:
Installed: (none)
Candidate: 0.14.1+noroms-0ubuntu6
Version table:
0.14.1+noroms-0ubuntu6 0
500 http://us.archive.ubuntu.com/ubuntu/ oneiric/universe amd64
Packages
-------------------------------------------------------------------------------------------------------------------------------------
Things I've tried:
I have been unable to get any useful info via gdb, local or remote.
I have been unable to reproduce this using a stripped down copy of main.
The core file I generated was deemed unusable by gdb.
I do not have a syslog inside the chroot (it was suggested that I post the
syslog from the guest).
There is nothing in the host's syslog to indicate that the OOM killer was
running.
I am attaching two stack traces for two different commands. In both
of those cases the problem exhibited as a hang.
I realize that this bug might lack some details/debugging info that
you need, so if you need more details or need me to test anything,
please contact me on IRC or via email.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/898474/+subscriptions
