qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] [Bug 898474] Re: aptitude in a lucid-based qemu-arm-static


From: Matt Fischer
Subject: [Qemu-devel] [Bug 898474] Re: aptitude in a lucid-based qemu-arm-static chroot segfaults/hangs, but works on real h/w
Date: Thu, 01 Dec 2011 04:56:34 -0000

One more bit of info:

There is a similar bug posted here, although they retitled it and
chalked it up to an unsupported platform:  http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=641270


** Bug watch added: Debian Bug tracker #641270
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641270

** Description changed:

  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:
  
  address@hidden:/# aptitude show totem
  Segmentation fault (core dumped)
  address@hidden:/# aptitude show totem
  <hangs here>
  ^C
  address@hidden:/# aptitude show totem
  Segmentation fault (core dumped)
  address@hidden:/# aptitude show totem
  <hangs here>
  ^C
  address@hidden:/# aptitude show totem
  <hangs here>
  ^C
  address@hidden:/# 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:
+ 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);
+      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();
+       printf("We never get here!");
+   _error->DumpErrors();
  ...
  
  
-------------------------------------------------------------------------------------------------------------------------------------
  Versions:
  
  chroot guest:
  address@hidden:/# uname -a
  Linux caprica 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 
armv7l GNU/Linux
  address@hidden:/# 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
- 
+   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:
- address@hidden:~/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
- address@hidden:~/Projects/charlotte-armel$ apt-cache policy qemu
- qemu:
-   Installed: (none)
-   Candidate: 0.14.1+noroms-0ubuntu6
+ address@hidden:~/Projects/charlotte-armel$ apt-cache policy qemu-user-static
+ qemu-user-static:
+   Installed: 0.15.50-2011.10-0ubuntu1~ppa11.10.1
+   Candidate: 0.15.50-2011.10-0ubuntu1~ppa11.10.1
    Version table:
-      0.14.1+noroms-0ubuntu6 0
+  *** 0.15.50-2011.10-0ubuntu1~ppa11.10.1 0
+         500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ 
oneiric/main amd64 Packages
+         100 /var/lib/dpkg/status
+      0.15.50-2011.08-0ubuntu4 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 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.

** Project changed: qemu => qemu-linaro

-- 
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 Linaro 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:

  address@hidden:/# aptitude show totem
  Segmentation fault (core dumped)
  address@hidden:/# aptitude show totem
  <hangs here>
  ^C
  address@hidden:/# aptitude show totem
  Segmentation fault (core dumped)
  address@hidden:/# aptitude show totem
  <hangs here>
  ^C
  address@hidden:/# aptitude show totem
  <hangs here>
  ^C
  address@hidden:/# 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:
  address@hidden:/# uname -a
  Linux caprica 3.0.0-13-generic #22-Ubuntu SMP Wed Nov 2 13:27:26 UTC 2011 
armv7l GNU/Linux
  address@hidden:/# 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:
  address@hidden:~/Projects/charlotte-armel$ apt-cache policy qemu-user-static
  qemu-user-static:
    Installed: 0.15.50-2011.10-0ubuntu1~ppa11.10.1
    Candidate: 0.15.50-2011.10-0ubuntu1~ppa11.10.1
    Version table:
   *** 0.15.50-2011.10-0ubuntu1~ppa11.10.1 0
          500 http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/ 
oneiric/main amd64 Packages
          100 /var/lib/dpkg/status
       0.15.50-2011.08-0ubuntu4 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-linaro/+bug/898474/+subscriptions



reply via email to

[Prev in Thread] Current Thread [Next in Thread]