RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1989338 - [Upstream] QEMU core dumped if launch with '-smp , maxcpus=4'
Summary: [Upstream] QEMU core dumped if launch with '-smp , maxcpus=4'
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: qemu-kvm
Version: 8.5
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: 8.6
Assignee: Paolo Bonzini
QA Contact: liunana
URL:
Whiteboard:
Depends On: 1997410
Blocks: 2001318
TreeView+ depends on / blocked
 
Reported: 2021-08-03 02:30 UTC by Yumei Huang
Modified: 2022-05-10 13:27 UTC (History)
8 users (show)

Fixed In Version: qemu-kvm-6.1.0-2.module+el8.6.0+12861+13975d62
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2001318 (view as bug list)
Environment:
Last Closed: 2022-05-10 13:20:17 UTC
Type: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-91998 0 None None None 2021-08-03 02:38:46 UTC
Red Hat Product Errata RHSA-2022:1759 0 None None None 2022-05-10 13:22:07 UTC

Description Yumei Huang 2021-08-03 02:30:28 UTC
Description of problem:
As in qemu-kvm man page says, "n" is optional,

   "-smp [[cpus=]n][,maxcpus=maxcpus][,sockets=sockets][,dies=dies][,cores=cores][,threads=threads]"

However, if launch qemu with '-smp ,maxcpus=4', qemu core dumped.


Version-Release number of selected component (if applicable):
qemu-kvm-6.1.0-1.rc1.scrmod+el8.5.0+12016+049b55fd.wrb210728
kernel-4.18.0-323.el8.x86_64

How reproducible:
always

Steps to Reproduce:
1. # /usr/libexec/qemu-kvm -smp ,maxcpus=4


Actual results:
qemu-kvm: ../qobject/qdict.c:369: qentry_destroy: Assertion `e->value != NULL' failed.
Aborted (core dumped)

Expected results:
QEMU quit with error message instead of core dump.

Additional info:
1. It's a regression.  qemu-kvm-6.0.0-16.module+el8.5.0+10848+2dccc46d works well.

2. "/usr/libexec/qemu-kvm -smp maxcpus=4,sockets=2,cores=2" works well.

3. (gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
        set = {__val = {0, 93825009086592, 0, 140737298297931, 93827783032832, 93825009086592, 
            93825009086592, 93825009086592, 93825009086592, 93825009086679, 93825009086692, 
            93825009086592, 93825009086692, 0, 0, 0}}
        pid = <optimized out>
        tid = <optimized out>
        ret = <optimized out>
#1  0x00007ffff4a67db5 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x555556567080, sa_sigaction = 0x555556567080}, 
          sa_mask = {__val = {0, 140737301732288, 140737299375648, 0, 0, 0, 140737488343752, 
              21474836480, 140737488343600, 140737299432112, 140737299416728, 0, 14713352540630688768, 
              140737299401645, 0, 140737299416728}}, sa_flags = 1442461189, 
          sa_restorer = 0x555555fa3627}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007ffff4a67c89 in __assert_fail_base (
    fmt=0x7ffff4bd0698 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
--Type <RET> for more, q to quit, c to continue without paging--
    assertion=0x555555fa3627 "e->value != NULL", file=0x555555fa3605 "../qobject/qdict.c", line=369, 
    function=<optimized out>) at assert.c:92
        str = 0x555556567080 ""
        total = 4096
#3  0x00007ffff4a75a76 in __GI___assert_fail (
    assertion=assertion@entry=0x555555fa3627 "e->value != NULL", 
    file=file@entry=0x555555fa3605 "../qobject/qdict.c", line=line@entry=369, 
    function=function@entry=0x555555fa3668 <__PRETTY_FUNCTION__.16005> "qentry_destroy") at assert.c:101
No locals.
#4  0x0000555555c3a736 in qentry_destroy (e=0x5555565670f0) at ../qobject/qdict.c:369
        __PRETTY_FUNCTION__ = "qentry_destroy"
        _obj = <optimized out>
        __mptr = <optimized out>
#5  qentry_destroy (e=0x5555565670f0) at ../qobject/qdict.c:365
        __PRETTY_FUNCTION__ = "qentry_destroy"
#6  0x0000555555c3b056 in qdict_destroy_obj (obj=<optimized out>) at ../qobject/qdict.c:438
        tmp = 0x0
--Type <RET> for more, q to quit, c to continue without paging--c
        entry = <optimized out>
        i = <optimized out>
        qdict = <optimized out>
        __PRETTY_FUNCTION__ = "qdict_destroy_obj"
#7  0x0000555555b11790 in qobject_unref_impl (obj=0x555556566020) at /usr/src/debug/qemu-kvm-6.1.0-1.rc1.scrmod+el8.5.0+12016+049b55fd.wrb210728.x86_64/include/qapi/qmp/qobject.h:93
        __PRETTY_FUNCTION__ = "qobject_unref_impl"
#8  machine_parse_property_opt (propname=0x555555cba45e "smp", errp=0x7fffffffd410, arg=<optimized out>, opts_list=<optimized out>) at ../softmmu/vl.c:1562
        opts = 0x555556566020
        prop = 0x0
        help = false
        _auto_errp_prop = {local_err = 0x555556567040, errp = 0x5555564e5070 <error_fatal>}
        opts = <optimized out>
        prop = <optimized out>
        help = <optimized out>
        _auto_errp_prop = <optimized out>
        _obj = <optimized out>
        __mptr = <optimized out>
        _obj = <optimized out>
        __mptr = <optimized out>
#9  qemu_init (argc=3, argv=0x7fffffffd628, envp=<optimized out>) at ../softmmu/vl.c:3341
        popt = <optimized out>
        opts = <optimized out>
        icount_opts = 0x0
        accel_opts = <optimized out>
        olist = <optimized out>
        optind = 3
        optarg = 0x7fffffffd9b5 ",maxcpus=4"
        machine_class = <optimized out>
        userconfig = <optimized out>
        vmstate_dump_file = 0x0
        __func__ = "qemu_init"
#10 0x000055555588cced in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../softmmu/main.c:49
No locals.

Comment 1 John Ferlan 2021-08-03 15:57:15 UTC
A bit of poor man's bisection lands on upstream commit a3c2f12830683e285e1ef32d459717dcdf9b70c6 which will be included in rc2

So I'll move this to POST w/ Paolo as the owner since he made that commit.

$ git co 526f1f3a5c6726e3d3b893d8063d31fda091c7e0
$ make -j5
...
$ ./build/x86_64-softmmu/qemu-system-x86_64 -smp ,maxcpus=4
qemu-system-x86_64: ../qobject/qdict.c:369: qentry_destroy: Assertion `e->value != NULL' failed.
Aborted (core dumped)
$ git co a3c2f12830683e285e1ef32d459717dcdf9b70c6
$ make -j5
...
./build/x86_64-softmmu/qemu-system-x86_64 -smp ,maxcpus=4
qemu-system-x86_64: -smp ,maxcpus=4: Invalid parameter ''
$ 

I'm not quite sure which ITM to set here as I'm not sure what the plans are yet. It'd be strange to move it to ON_QA & VERIFIED as soon as Mirek merges in rc2...  Still I'll leave a needinfo on Mirek mostly for his awareness. Mirek feel free to just clear the needinfo (and of course making sure the various knobs are twisted as you expect them in order to move this along once rc2 is merged in).

FWIW: Yes, the same problem would exist if we did the same processing using rc1 for RHEL9, but since I believe we don't have that yet, let's not go there yet.

Comment 4 Yanan Fu 2021-08-06 08:26:24 UTC
This issue gone with rc2, can get the expected result in comment 1.

Test version:
weeklyrebase build:  qemu-kvm-core-6.1.0-1.rc2.scrmod+el8.5.0+12133+c45b5bc2.wrb210804.x86_64

Test step:
# /usr/libexec/qemu-kvm -smp ,maxcpus=4
qemu-kvm: -smp ,maxcpus=4: Invalid parameter ''

Comment 5 John Ferlan 2021-09-05 14:00:08 UTC
Move to RHEL since RHEL-AV will only be a rebuild of RHEL starting w/ 8.6.0

Added the RHEL rebase bz to depends on list

Comment 11 Yanan Fu 2021-10-13 03:08:01 UTC
Set 'Verified:Tested,SanityOnly' as gating test with qemu-kvm-6.1.0-2.module+el8.6.0+12861+13975d62 pass.

Comment 12 liunana 2021-10-13 13:59:25 UTC
Verified this bug on qemu-kvm-6.1.0-2.module+el8.6.0+12861+13975d62.
# /usr/libexec/qemu-kvm -smp ,maxcpus=4
qemu-kvm: -smp ,maxcpus=4: Invalid parameter ''


Test Env:
   dell-per6515-04.lab.eng.pek2.redhat.com
   4.18.0-345.1.el8.x86_64
   qemu-kvm-6.1.0-2.module+el8.6.0+12861+13975d62.x86_64

I will move this bug to verified now.


Besides, do we support 'maxcpus=0'?
I get error output while booting qemu with '-smp 0,maxcpus=0':
# /usr/libexec/qemu-kvm -smp 0,maxcpus=0
qemu-kvm: maxcpus must be equal to or greater than smp

But qemu works with command '-smp 0'.
# /usr/libexec/qemu-kvm -smp 0
VNC server running on ::1:5900


Could you please help to check this? Thanks!



Best regards
Liu Nana

Comment 13 Paolo Bonzini 2021-10-13 14:58:56 UTC
Hi Nana,

-smp 0 works but it's more or less an implementation detail.  It could break in future versions; libvirt never uses it.

Comment 15 errata-xmlrpc 2022-05-10 13:20:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:1759


Note You need to log in before you can comment on or make changes to this bug.