qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] [Bug 898474] [NEW] aptitude in a lucid-based qemu-arm-stati


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

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:

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

  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$ 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
    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



reply via email to

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