*** Bug 1776818 has been marked as a duplicate of this bug. ***

Confirmed that the problem is still upstream with the final qemu 4.2 release.  Reduced duplication:

$ qemu-img create -f qcow2 f1 100m
$ qemu-img create -f qcow2 f2 100m
$ ./qemu-kvm -nodefaults -nographic -qmp stdio -object iothread,id=io0 \
 -drive driver=qcow2,id=drive1,file=f1,if=none -device virtio-scsi-pci,id=scsi0,iothread=io0 -device scsi-hd,id=image1,drive=drive1 \
 -drive driver=qcow2,id=drive2,file=f2,if=none -device virtio-blk-pci,id=image2,drive=drive2,iothread=io0

{'execute':'qmp_capabilities'}

{'execute':'transaction','arguments':{'actions':[ {'type':'blockdev-snapshot-sync','data':{'device':'drive1', 'snapshot-file':'sn1','mode':'absolute-paths','format':'qcow2'}}, {'type':'blockdev-snapshot-sync','data':{'device':'drive2', 'snapshot-file':'/aa/sn1','mode':'absolute-paths','format':'qcow2'}}]}}

and removing -object iothread indeed avoids the problem.  Definitely a missed context switch somewhere along the error path.

assertion is still present even after applying https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg04788.html blockdev: avoid acquiring AioContext lock twice at do_drive_backup and do_blockdev_backup

QEMU has been recently split into sub-components and as a one-time operation to avoid breakage of tools, we are setting the QEMU sub-component of this BZ to "General". Please review and change the sub-component if necessary the next time you review this BZ. Thanks

Verified on qemu-kvm-4.2.0-10.module+el8.2.0+5740+c3dff59e, the issue has been resolved, set bug's status to "Verified".

Test Steps:
 1.Start guest with qemu cmds:
    /usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1' \
    -machine q35  \
    -nodefaults \
    -device VGA,bus=pcie.0,addr=0x1 \
    -m 7168  \
    -smp 4,maxcpus=4,cores=2,threads=1,dies=1,sockets=2  \
    -cpu 'Skylake-Client',+kvm_pv_unhalt  \
    -chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/monitor-qmpmonitor1-20191118-011823-gEG3j1ms,server,nowait \
    -mon chardev=qmp_id_qmpmonitor1,mode=control  \
    -chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/monitor-catch_monitor-20191118-011823-gEG3j1mt,server,nowait \
    -mon chardev=qmp_id_catch_monitor,mode=control \
    -device pvpanic,ioport=0x505,id=id4p8G4l \
    -chardev socket,server,id=chardev_serial0,path=/var/tmp/serial-serial0-20191118-011823-gEG3j1mt,nowait \
    -device isa-serial,id=serial0,chardev=chardev_serial0  \
    -chardev socket,id=seabioslog_id_20191118-011823-gEG3j1mt,path=/var/tmp/seabios-20191118-011823-gEG3j1mt,server,nowait \
    -device isa-debugcon,chardev=seabioslog_id_20191118-011823-gEG3j1mt,iobase=0x402 \
    -device pcie-root-port,id=pcie.0-root-port-2,slot=2,chassis=2,addr=0x2,bus=pcie.0 \
    -device qemu-xhci,id=usb1,bus=pcie.0-root-port-2,addr=0x0 \
    -object iothread,id=iothread0 \
    -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/mnt/nfs/rhel820-64-virtio.qcow2 \
    -device pcie-root-port,id=pcie.0-root-port-3,slot=3,chassis=3,addr=0x3,bus=pcie.0 \
    -device virtio-scsi-pci,id=scsi0,bus=pcie.0-root-port-3,addr=0x0,iothread=iothread0 \
    -device scsi-hd,id=image1,drive=drive_image1,bootindex=0,bus=scsi0.0 \
    -drive id=drive_data1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/mnt/nfs/data.qcow2 \
    -device pcie-root-port,id=pcie.0-root-port-6,slot=6,chassis=6,addr=0x6,bus=pcie.0 \
    -device virtio-blk-pci,id=data1,drive=drive_data1,bus=pcie.0-root-port-6,addr=0x0,iothread=iothread0 \
    -device pcie-root-port,id=pcie.0-root-port-4,slot=4,chassis=4,addr=0x4,bus=pcie.0 \
    -device virtio-net-pci,mac=9a:4f:f4:e5:bd:67,id=idkQvhgf,netdev=idnMcj5J,bus=pcie.0-root-port-4,addr=0x0  \
    -netdev tap,id=idnMcj5J,vhost=on \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -vnc :0  \
    -rtc base=utc,clock=host,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -enable-kvm \
    -device pcie-root-port,id=pcie_extra_root_port_0,slot=5,chassis=5,addr=0x5,bus=pcie.0 \
    -monitor stdio \

2.Do snapshot in transaction mode with one snapshot path not exist.
    {"execute": "transaction", "arguments": { "actions": [ {"type": "blockdev-snapshot-sync","data": {"device": "drive_image1","snapshot-file": "sn1","mode": "absolute-paths","format": "qcow2" } },{"type": "blockdev-snapshot-sync","data": {"device": "drive_data1","snapshot-file": "/aa/sn1","mode": "absolute-paths","format": "qcow2" } }]}}
    {"error": {"class": "GenericError", "desc": "Could not create file: No such file or directory"}}

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, 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/RHBA-2020:2017