qemu crashes with "GLib-ERROR **: gmem.c" error when a negative value passed to "maxcpus"

[R.Nageswara Sastry]

# 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 <raise+56>
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.

[R.Nageswara Sastry (nasastry)]

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.

[R.Nageswara Sastry (nasastry)]

The above I am referring from hw/ppc/spapr.c

[Thomas Huth (th-huth)]

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!

[Thomas Huth (th-huth)]

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.

[R.Nageswara Sastry (nasastry)]

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.

[Peter Maydell (pmaydell)]

Fixed in master, commit c0dd109919, which will be in the upcoming 2.11 release.