Re: [PULL 23/29] ui & main loop: Redesign of system-specific main thread event handling

["Philippe Mathieu-Daudé" <philmd@linaro.org>]

On 1/4/25 13:43, David Woodhouse wrote:
> On Tue, 2025-04-01 at 13:30 +0200, Philippe Mathieu-Daudé wrote:
>> On 1/4/25 13:18, Philippe Mathieu-Daudé wrote:
>>> Hi David,
>>>
>>> On 8/1/25 14:51, David Woodhouse wrote:
>>>> On Tue, 2024-12-31 at 21:22 +0100, Philippe Mathieu-Daudé wrote:
>>>>>
>>>>> This change tidies up main thread management to be more
>>>>> flexible.
>>>>>
>>>>>    * The qemu_main global function pointer is a custom function
>>>>> for the
>>>>>      main thread, and it may now be NULL. When it is, the main
>>>>> thread
>>>>>      runs the main Qemu loop. This represents the traditional
>>>>> setup.
>>>>>    * When non-null, spawning the main Qemu event loop on a
>>>>> separate
>>>>>      thread is now done centrally rather than inside the Cocoa
>>>>> UI code.
>>>>>    * For most platforms, qemu_main is indeed NULL by default,
>>>>> but on
>>>>>      Darwin, it defaults to a function that runs the CFRunLoop.
>>>>>    * The Cocoa UI sets qemu_main to a function which runs the
>>>>>      NSApplication event handling runloop, as is usual for a
>>>>> Cocoa app.
>>>>>    * The SDL UI overrides the qemu_main function to NULL, thus
>>>>>      specifying that Qemu's main loop must run on the main
>>>>>      thread.
>>>>>    * The GTK UI also overrides the qemu_main function to NULL.
>>>>>    * For other UIs, or in the absence of UIs, the platform's
>>>>> default
>>>>>      behaviour is followed.
>>>>
>>>> When exiting an emulated Xen guest with <Ctrl-a x> on the
>>>> console, I
>>>> now see:
>>>>
>>>> (gdb) run
>>>> Starting program: /home/dwmw2/git/qemu/ball/qemu-system-x86_64 -
>>>> display none -vga none -serial mon:stdio -machine q35 -accel
>>>> kvm,xen-
>>>> version=0x4000a,kernel-irqchip=split -smp 2 -kernel /home/dwmw2/
>>>> avocado/data/cache/by_name/bzImage -append printk.time=0\
>>>> root=/dev/
>>>> xvda\ console=ttyS0\ xen_emul_unplug=ide-disks\
>>>> xen_no_vector_callback\ noapic\ loglevel=0 -drive
>>>> file=/home/dwmw2/
>>>> avocado/data/cache/by_name/
>>>> rootfs.ext4,if=none,snapshot=on,format=raw,id=drv0 -device xen-
>>>> disk,drive=drv0,vdev=xvda -device virtio-net-pci,netdev=unet -
>>>> netdev
>>>> user,id=unet,hostfwd=:127.0.0.1:0-:22
>>>>
>>>> Starting syslogd: OK
>>>> Starting klogd: OK
>>>> Running sysctl: OK
>>>> Saving 256 bits of non-creditable seed for next boot
>>>> Starting network: OK
>>>> Starting dhcpcd...
>>>> no such user dhcpcd
>>>> dhcpcd-9.4.1 starting
>>>> no interfaces have a carrier
>>>> forked to background, child pid 111
>>>> Starting dropbear sshd: OK
>>>> #
>>>> QEMU: Terminated
>>>> qemu-system-x86_64: ../block/block-backend.c:1290: blk_in_drain:
>>>> Assertion `qemu_in_main_thread()' failed.
>>>>
>>>> Thread 1 "qemu-system-x86" received signal SIGABRT, Aborted.
>>>> 0x00007ffff5ffc724 in __pthread_kill_implementation () from
>>>> /lib64/
>>>> libc.so.6
>>>> (gdb) bt
>>>> #0  0x00007ffff5ffc724 in __pthread_kill_implementation () at
>>>> /lib64/
>>>> libc.so.6
>>>> #1  0x00007ffff5fa3d1e in raise () at /lib64/libc.so.6
>>>> #2  0x00007ffff5f8b942 in abort () at /lib64/libc.so.6
>>>> #3  0x00007ffff5f8b85e in __assert_fail_base.cold () at
>>>> /lib64/libc.so.6
>>>> #4  0x00007ffff5f9be47 in __assert_fail () at /lib64/libc.so.6
>>>> #5  0x0000555555abf911 in blk_in_drain (blk=0x555557ca6680)
>>>>       at ../block/block-backend.c:1290
>>>> #6  0x000055555593410c in xen_block_dataplane_stop
>>>> (dataplane=0x555558982950)
>>>>       at ../hw/block/dataplane/xen-block.c:695
>>>> #7  0x000055555593441a in xen_block_dataplane_stop
>>>> (dataplane=<optimized out>)
>>>>       at ../hw/block/dataplane/xen-block.c:689
>>>> #8  0x00005555555dfd5e in xen_block_disconnect
>>>>       (xendev=xendev@entry=0x55555880aa60, errp=<optimized out>)
>>>>       at ../hw/block/xen-block.c:172
>>>> #9  0x00005555555dfeca in xen_block_unrealize
>>>> (xendev=0x55555880aa60)
>>>>       at ../hw/block/xen-block.c:282
>>>> #10 0x000055555578ef71 in xen_device_unrealize (dev=<optimized
>>>> out>)
>>>>       at ../hw/xen/xen-bus.c:978
>>>> #11 0x0000555555bfe65f in notifier_list_notify (list=<optimized
>>>> out>,
>>>> data=0x0)
>>>>       at ../util/notify.c:39
>>>> #12 0x00007ffff5fa6461 in __run_exit_handlers () at
>>>> /lib64/libc.so.6
>>>> #13 0x00007ffff5fa652e in exit () at /lib64/libc.so.6
>>>> #14 0x0000555555b523dc in qemu_default_main
>>>> (opaque=opaque@entry=0x0)
>>>> #15 0x00005555555609c0 in main (argc=<optimized out>,
>>>> argv=<optimized
>>>> out>) at ../system/main.c:76
>>>>
>>>
>>> Is this still an issue?
>>
>> Likely fixed by commit e7bc0204 ("system/runstate:
>> Fix regression, clarify BQL status of exit notifiers"), so
>> I'm closing https://gitlab.com/qemu-project/qemu/-/issues/2771.
> 
> Indeed. I think I was assuming the explicit Resolves: tag in that
> commit was going to magically close the issue when it was merged.
> Should I have closed it manually?

It should have been closed automatically. Maybe some transient
problem on GitLab side ¯\_(ツ)_/¯