> On Wed, Jul 20, 2022 at 11:36:07AM +0400, Marc-André Lureau wrote: > > Hi > > > > On Wed, Jul 20, 2022 at 11:13 AM Hogan Wang via > > <qemu-devel@nongnu.org> > > wrote: > > > > > IOWatchPoll object did not hold the @ioc and @src objects reference, > > > then io_watch_poll_prepare execute in IO thread, if IOWatchPoll > > > removed by mian thread, then io_watch_poll_prepare access @ioc or > > > > > > > mian->main > > > > > > > @src concurrently lead to coredump. > > > > > > In IO thread monitor scene, the IO thread used to accept client, > > > receive qmp request and handle hung-up event. Main thread used to > > > handle qmp request and send response, it will remove IOWatchPoll and > > > free @ioc when send response fail, then cause use-after-free > > > > > > > I wonder if we are misusing GSources in that case, by removing sources > > from different threads.. Could you be more specific about the code > > path that leads to that? > > It is permitted, but unfortunately every version of glib prior to 2.64 has a > race condition that means you'll periodically get a use-after-free and a > crash: > > https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1358 > > Libvirt worked around this problem by not calling 'g_source_unref' > directly, but instead have a helper that uses g_idle_add to delay the unref > such that its guaranteed to happen inside the main event loop thread. > > So I'd like to know what version of glib Hogan is using
I am using glib2-2.62.5 in test environment, so it's looks like a glib2 known issue. > > With regards, > Daniel > -- >|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| >|: https://libvirt.org -o- https://fstop138.berrange.com :| >|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
