[Qemu-devel] [Bug 1154328] [NEW] qemu locks up on typing 41 characters at once into serial console

[Andreas Gustafsson]

Public bug reported:

I am running daily automated tests that involve booting a NetBSD 6.0.1
guest in qemu freshly built from git.  The tests are scripted using
pexpect, which interacts with the NetBSD guest over the emulated
serial console.  Recently, the tests stopped working; the guest boots
and pexpect is able to log in, but when it sends a long shell command
(more than 40 characters) to the guest, the command is neither echoed
nor executed, and no further output is seen from the guest.

The problem can be reproduced manually (without pexpect) as follows.

Run the following commands in a terminal window on a host of
your choice (Linux will do fine):

  wget http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
  gunzip NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
  qemu-system-i386 -m 32 -nographic -snapshot -hda 
NetBSD-6.0.1-i386-live-wd0root-com0.img

This will download a disk image (some 144 MB compressed, 2 GB
uncompressed) containing a NetBSD system configured to use a serial
console, and boot it in qemu.  Make sure the qemu-system-i386
in your PATH is one recently built from git, or adjust the command
as needed.

Once the VM has booted, log in as root (there is no password).  You
will now be in a functional NetBSD root shell.

Now cut-and-paste a string containing at least 41 characters into the
terminal window.  I used a string containing 41 copies of the letter
"X".  You can use other strings, but beware of pasting strings
containing valid shell commands, as they may end up being executed on
the host (see below).

If your copy of qemu is suffering from the bug, it will lock up.  Not
only will the virtual machine no longer respond to keystrokes, but
qemu itself will no longer respond to commands such as "control-a c".
You will have to kill it from a different terminal window.  When the
qemu process is killed, any pasted characters after the first 40 will
be read and executed by the host shell, suggesting that they were never
even read by the qemu process.  As I had typed a return after pasting
the 41 X:es, the host shell executed the command "X", thereby
accidentally attempting (unsuccessfully) to start an X server.

"git bisect" implicates the following commit:

  commit a29753f8aa79a34a324afebe340182a51a5aef11
  Author: Anthony Liguori <address@hidden>
  Date:   Tue Mar 5 23:21:19 2013 +0530

      qemu-char: convert fd_chr to use a GIOChannel

         This uses the newly introduced IOWatchPoll source.

      Signed-off-by: Anthony Liguori <address@hidden>
      Signed-off-by: Amit Shah <address@hidden>
      Message-id: address@hidden
      Signed-off-by: Anthony Liguori <address@hidden>

** 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/1154328

Title:
  qemu locks up on typing 41 characters at once into serial console

Status in QEMU:
  New

Bug description:
  I am running daily automated tests that involve booting a NetBSD 6.0.1
  guest in qemu freshly built from git.  The tests are scripted using
  pexpect, which interacts with the NetBSD guest over the emulated
  serial console.  Recently, the tests stopped working; the guest boots
  and pexpect is able to log in, but when it sends a long shell command
  (more than 40 characters) to the guest, the command is neither echoed
  nor executed, and no further output is seen from the guest.

  The problem can be reproduced manually (without pexpect) as follows.

  Run the following commands in a terminal window on a host of
  your choice (Linux will do fine):

    wget 
http://www.gson.org/bugs/qemu/NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
    gunzip NetBSD-6.0.1-i386-live-wd0root-com0.img.gz
    qemu-system-i386 -m 32 -nographic -snapshot -hda 
NetBSD-6.0.1-i386-live-wd0root-com0.img

  This will download a disk image (some 144 MB compressed, 2 GB
  uncompressed) containing a NetBSD system configured to use a serial
  console, and boot it in qemu.  Make sure the qemu-system-i386
  in your PATH is one recently built from git, or adjust the command
  as needed.

  Once the VM has booted, log in as root (there is no password).  You
  will now be in a functional NetBSD root shell.

  Now cut-and-paste a string containing at least 41 characters into the
  terminal window.  I used a string containing 41 copies of the letter
  "X".  You can use other strings, but beware of pasting strings
  containing valid shell commands, as they may end up being executed on
  the host (see below).

  If your copy of qemu is suffering from the bug, it will lock up.  Not
  only will the virtual machine no longer respond to keystrokes, but
  qemu itself will no longer respond to commands such as "control-a c".
  You will have to kill it from a different terminal window.  When the
  qemu process is killed, any pasted characters after the first 40 will
  be read and executed by the host shell, suggesting that they were never
  even read by the qemu process.  As I had typed a return after pasting
  the 41 X:es, the host shell executed the command "X", thereby
  accidentally attempting (unsuccessfully) to start an X server.

  "git bisect" implicates the following commit:

    commit a29753f8aa79a34a324afebe340182a51a5aef11
    Author: Anthony Liguori <address@hidden>
    Date:   Tue Mar 5 23:21:19 2013 +0530

        qemu-char: convert fd_chr to use a GIOChannel

           This uses the newly introduced IOWatchPoll source.

        Signed-off-by: Anthony Liguori <address@hidden>
        Signed-off-by: Amit Shah <address@hidden>
        Message-id: address@hidden
        Signed-off-by: Anthony Liguori <address@hidden>

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1154328/+subscriptions