** Attachment added: "strace log for aptitude show totem" https://bugs.launchpad.net/qemu/+bug/898474/+attachment/2614332/+files/show.log
-- 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
