other: 0.941 KVM: 0.909 vnc: 0.906 graphic: 0.905 permissions: 0.894 files: 0.894 performance: 0.886 device: 0.880 debug: 0.879 semantic: 0.876 PID: 0.859 socket: 0.840 network: 0.825 boot: 0.793 qemu crashes with "GLib-ERROR **: gmem.c" error when a negative value passed to "maxcpus" # ppc64-softmmu/qemu-system-ppc64 --nographic -vga none -machine pseries,accel=kvm,kvm-type=HV -m size=20g -device virtio-blk-pci,drive=rootdisk -drive file=/home/nasastry/avocado-fvt-wrapper/data/avocado-vt/images/pegas-1.0-ppc64le.qcow2,if=none,cache=none,id=rootdisk,format=qcow2 -monitor telnet:127.0.0.1:1234,server,nowait -net nic,model=virtio -net user -device nec-usb-xhci -smp 8,cores=1,threads=1,maxcpus=-12 (process:12149): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes From GDB: [New Thread 0x3fffb5aceb60 (LWP 12190)] (process:12184): GLib-ERROR **: gmem.c:130: failed to allocate 18446744073709550568 bytes Program received signal SIGTRAP, Trace/breakpoint trap. 0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install glib2-2.50.3-3.el7.ppc64le glibc-2.17-196.el7.ppc64le gnutls-3.3.26-9.el7.ppc64le krb5-libs-1.15.1-8.el7.ppc64le libgcc-4.8.5-16.el7.ppc64le libstdc++-4.8.5-16.el7.ppc64le ncurses-libs-5.9-13.20130511.el7.ppc64le nss-3.28.4-8.el7.ppc64le nss-softokn-freebl-3.28.3-6.el7.ppc64le nss-util-3.28.4-3.el7.ppc64le openldap-2.4.44-5.el7.ppc64le openssl-libs-1.0.2k-8.el7.ppc64le p11-kit-0.23.5-3.el7.ppc64le (gdb) bt #0 0x00003fffb75e5408 in raise () from /lib64/libpthread.so.0 #1 0x00003fffb796be9c in _g_log_abort () from /lib64/libglib-2.0.so.0 #2 0x00003fffb796d4c4 in g_log_default_handler () from /lib64/libglib-2.0.so.0 #3 0x00003fffb796d86c in g_logv () from /lib64/libglib-2.0.so.0 #4 0x00003fffb796db00 in g_log () from /lib64/libglib-2.0.so.0 #5 0x00003fffb796b694 in g_malloc0 () from /lib64/libglib-2.0.so.0 #6 0x000000001018fa84 in spapr_possible_cpu_arch_ids (machine=0x11165660) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:3322 #7 0x000000001018b444 in spapr_init_cpus (spapr=0x11165660) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2096 #8 0x000000001018bc6c in ppc_spapr_init (machine=0x11165660) at /home/nasastry/upstream/qemu/hw/ppc/spapr.c:2275 #9 0x000000001041ca38 in machine_run_board_init (machine=0x11165660) at hw/core/machine.c:760 #10 0x000000001037723c in main (argc=24, argv=0x3ffffffff108, envp=0x3ffffffff1d0) at vl.c:4633 (gdb) i r r0 0xfa 250 r1 0x3fffffffe450 70368744170576 r2 0x3fffb7608100 70367525765376 r3 0x0 0 r4 0x2f98 12184 r5 0x5 5 r6 0x0 0 r7 0x3fffa8000020 70367267782688 r8 0x2f98 12184 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 r13 0x3fffb64fccb0 70367507893424 r14 0x0 0 r15 0x0 0 r16 0x0 0 r17 0x0 0 r18 0x1 1 r19 0x0 0 r20 0x3fffb796d3f0 70367529325552 r21 0x0 0 r22 0x20000000 536870912 r23 0x1 1 r24 0x3fffb7a61498 70367530325144 r25 0x3fffb7a614e8 70367530325224 r26 0x3fffb7a61488 70367530325128 r27 0x3fffa80008c0 70367267784896 r28 0x3fffb79cd2a8 70367529718440 r29 0x3fffb79cd2a8 70367529718440 r30 0xffffffffffffffff 18446744073709551615 r31 0x1 1 pc 0x3fffb75e5408 0x3fffb75e5408 msr 0x900000000000d033 10376293541461676083 cr 0x42244842 1109674050 lr 0x3fffb796be9c 0x3fffb796be9c <_g_log_abort+60> ctr 0x0 0 xer 0x0 0 orig_r3 0x2f98 12184 trap 0xc00 3072 Similar error observed on x86_64 and PPC64LE architectures. 3308 static const CPUArchIdList *spapr_possible_cpu_arch_ids(MachineState *machine) 3309 { 3310 int i; 3311 int spapr_max_cores = max_cpus / smp_threads; <<<<<< max_cpus is -ve and spapr_max_cores will also be -ve ... 3321 3322 machine->possible_cpus = g_malloc0(sizeof(CPUArchIdList) + 3323 sizeof(CPUArchId) * spapr_max_cores); g_malloc0(is getting a -ve value) and then fails with a trap. The above I am referring from hw/ppc/spapr.c Please don't add patches to the bug tracker, post them to the qemu-devel (and qemu-ppc in this case) mailing list instead. You even don't have to join the mailing lists if you don't like to, posting to them is allowed for everybody. See https://www.qemu.org/contribute/report-a-bug/ and http://wiki.qemu.org/Contribute/SubmitAPatch for details. Thanks! Looking at your patch, I think you should also check for "<= 0" instead of just "< 0" ... since maxcpus = 0 also does not make much sense. Sure will do the changes and update. Seems one of my colleague did it already (sent patch to devel list) https://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg05345.html I will pass your review comments to her for modification. Thanks for your review. Fixed in master, commit c0dd109919, which will be in the upcoming 2.11 release.