ubuntu18.04 - qemu segfaults when tries to dump-guest-memory

[bugproxy]

---Problem Description---
qemu segfaults when tried to dump-guest-memory

---uname output---
Linux ltc-boston122 4.13.0-12-generic #13-Ubuntu SMP Fri Sep 22 20:52:52 UTC 2017 ppc64le ppc64le ppc64le GNU/Linux

Machine Type = PowerNV 5104-22C

---Steps to Reproduce---
 1. Run the following commands
# qemu-system-ppc64 -M none -nographic -m 256
QEMU 2.10.0 monitor - type 'help' for more information
(qemu) dump-guest-memory /dev/null
Segmentation fault

== Comment: #1 - NAGESWARA R. SASTRY <email address hidden> - 2017-10-08 23:06:29 ==
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
Core was generated by `qemu-system-ppc64 -M none -nographic -m 256 '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000001cea97af410 in object_get_class ()
[Current thread is 1 (Thread 0x798c498ef7e0 (LWP 49591))]
(gdb) bt
#0 0x000001cea97af410 in object_get_class ()
#1 0x000001cea952ce30 in cpu_get_dump_info ()
#2 0x000001cea93c1d48 in qmp_dump_guest_memory ()
#3 0x000001cea95afae8 in hmp_dump_guest_memory ()
#4 0x000001cea93a5c98 in ?? ()
#5 0x000001cea93a60ec in ?? ()
#6 0x000001cea98f7388 in readline_handle_byte ()
#7 0x000001cea93a5ff8 in ?? ()
#8 0x000001cea98541f0 in ?? ()
#9 0x000001cea984dc94 in qemu_chr_be_write ()
Backtrace stopped: frame did not save the PC
(gdb) i r
r0 0x1cea93c1d48 1987114179912
r1 0x7fffd5f06920 140736782690592
r2 0x1cea9c07900 1987122854144
r3 0x0 0
r4 0x1cea993c000 1987119923200
r5 0x1cea9942db8 1987119951288
r6 0xe3 227
r7 0x1cea9942d58 1987119951192
r8 0x10000000 268435456
r9 0x0 0
r10 0x0 0
r11 0x0 0
r12 0x4000 16384
r13 0x798c498f6f40 133643436519232
r14 0x6 6
r15 0x1cea99d37d0 1987120543696
r16 0x7fffd5f06de0 140736782691808
r17 0x1 1
r18 0x0 0
r19 0x1cea99fee28 1987120721448
r20 0x1cecf558b20 1987753380640
r21 0x1cea9c97900 1987123443968
r22 0x0 0
r23 0x1cea9c97900 1987123443968
r24 0x0 0
r25 0x1cea9c8fac0 1987123411648
r26 0x1cea9c8faf0 1987123411696
r27 0x0 0
r28 0x1cea9942d58 1987119951192
r29 0x1cea9942db8 1987119951288
r30 0x1cea993c000 1987119923200
r31 0x1cea9c8fad8 1987123411672
pc 0x1cea97af410 0x1cea97af410 <object_get_class>
msr 0x900000000000f033 10376293541461684275
cr 0x28024242 671236674
lr 0x1cea952ce30 0x1cea952ce30 <cpu_get_dump_info+112>
ctr 0x798c49cb1a70 133643440429680
xer 0x0 0
orig_r3 0x1cea952ce2c 1987115666988
trap 0x300 768

== Comment: #3 - Vaishnavi Bhat <email address hidden> - 2017-10-09 05:48:09 ==
This issue is already fixed upstream:

https://github.com/qemu/qemu/commit/b1fde1ef5106c92dd12f1f0cfcb8c76e57d7f681

The new behavior is to reject dump when you don't have a CPU:

(qemu) dump-guest-memory /dev/null
this feature or command is not currently supported

== Comment: #4 - Vaishnavi Bhat <email address hidden> - 2017-10-09 06:25:34 ==
Verified with the upstream qemu -
# ./qemu-system-ppc -M none -nographic -m 256
QEMU 2.10.50 monitor - type 'help' for more information
(qemu) dump-guest-memory /dev/null
this feature or command is not currently supported
(qemu)

[bugproxy (bugproxy)]

Default Comment by Bridge

[Christian Ehrhardt  (paelzer)]

Hi,
the default cpu will be something useful "pseries-artful" which exists to manage backports/migrations but so far is a full copy of "pseries-2.10".

# As one might assume with that I can dump just fine:
(qemu) dump-guest-memory /root/testdump
root@cpaelzer-artful-kvm:~# ll testdump
-r-------- 1 root root 268437440 Oct 18 13:32 testdump
# file testdump
testdump: ELF 64-bit MSB core file 64-bit PowerPC or cisco 7500, version 1 (SYSV), SVR4-style

While I appreciate fixing this in general and thank you for bringing it upstream - is there a need to pick this up faster than on the next qemu merge?
That would be likely qemu 2.11 (which contains this fix) for Ubuntu 18.04.

Setting to low and marking for 18.04 unless discussed otherwise.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-11-11 20:41 EDT-------
I agree this can wait Ubuntu 18.04.

[Christian Ehrhardt  (paelzer)]

qemu 2.11 is in proposed

[Launchpad Janitor (janitor)]

This bug was fixed in the package qemu - 1:2.11+dfsg-1ubuntu1

---------------
qemu (1:2.11+dfsg-1ubuntu1) bionic; urgency=medium

  * Merge with Debian testing, among other fixes this includes
    - fix fatal error on negative maxcpus (LP: #1722495)
    - fix segfault on dump-guest-memory on guests without memory (LP: #1723381)
    - linux user threading issues (LP: #1350435)
    - TOD-Clock Epoch Extension Support on s390x (LP: #1732691)
    Remaining changes:
    - qemu-kvm to systemd unit
      - d/qemu-kvm-init: script for QEMU KVM preparation modules, ksm,
        hugepages and architecture specifics
      - d/qemu-kvm.service: systemd unit to call qemu-kvm-init
      - d/qemu-system-common.install: install systemd unit and helper script
      - d/qemu-system-common.maintscript: clean old sysv and upstart scripts
      - d/qemu-system-common.qemu-kvm.default: defaults for
        /etc/default/qemu-kvm
      - d/rules: install /etc/default/qemu-kvm
    - Enable nesting by default
      - set nested=1 module option on intel. (is default on amd)
      - re-load kvm_intel.ko if it was loaded without nested=1
      - d/p/ubuntu/expose-vmx_qemu64cpu.patch: expose nested kvm by default
        in qemu64 cpu type.
      - d/p/ubuntu/enable-svm-by-default.patch: Enable nested svm by default
        in qemu64 on amd
    - libvirt/qemu user/group support
      - qemu-system-common.postinst: remove acl placed by udev, and add udevadm
        trigger.
      - qemu-system-common.preinst: add kvm group if needed
    - Distribution specific machine type
      - d/p/ubuntu/define-ubuntu-machine-types.patch: define distro machine
        types to ease future live vm migration.
      - d/qemu-system-x86.NEWS Info on fixed machine type defintions
    - improved dependencies
      - Make qemu-system-common depend on qemu-block-extra
      - Make qemu-utils depend on qemu-block-extra
      - let qemu-utils recommend sharutils
    - s390x support
      - Create qemu-system-s390x package
      - Include s390-ccw.img firmware
      - Enable numa support for s390x
    - ppc64[le] support
      - d/qemu-system-ppc.links provide usr/bin/qemu-system-ppc64le symlink
    - arch aware kvm wrappers
  * Added Changes
    - update VCS-git to match the bionic branch
    - sdl2 is yet too unstable for the LTS Ubuntu release given the reports
      we still see upstream and in Debian - furthermore sdl2 isn't in main yet,
      so we revert related changes to stick with the proven for now:
      - 0fd25810 - do not build-depend on libx11-dev (libsdl2-dev already
                   depends on it)
      - 9594f820 - switch from sdl1.2 to sdl2 (#870025)
    - d/qemu-system-x86.README.Debian: document intention of nested being
      default is comfort, not full support
    - update Ubuntu machine types for qemu 2.11
    - qemu-guest-agent: freeze-hook fixes (LP: #1484990)
      - d/p/guest-agent-freeze-hook-skip-dpkg-artifacts.patch
      - d/qemu-guest-agent.install: provide /etc/qemu/fsfreeze-hook
      - d/qemu-guest-agent.dirs: provide /etc/qemu/fsfreeze-hook.d
    - Create and install pxe netboot images for KVM s390x (LP: #1732094)
      - d/rules enable install s390x-netbo...

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-09-28 02:31 EDT-------
Tested and verified on following build

qemu 1:2.11+dfsg-1ubuntu7.5

# cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.1 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.1 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic

# uname -r
4.19.0-rc3-00116-g72664e47565f

Log
# qemu-system-ppc64 -M none -nographic -m 256
QEMU 2.11.1 monitor - type 'help' for more information
(qemu)

The issue is fixed.