[Webkit-unassigned] [Bug 276819] WPENetworkProcess segfaults occasionaly after logging assertion errors
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sun Sep 15 12:36:38 PDT 2024
https://bugs.webkit.org/show_bug.cgi?id=276819
--- Comment #6 from Michael Catanzaro <mcatanzaro at redhat.com> ---
Clearly we have a refcounting error on that GTask causing it to be finalized before the task completes. I suspect a bug somewhere in libsoup. I doubt it's a WebKit-level bug, because WebKit doesn't have access to this GTask. If we're really unlucky it could be https://gitlab.gnome.org/GNOME/glib/-/issues/1346, since I see the GTask is owned by SoupMessageQueueItem and that gets passed across threads, but hopefully not.
The rest of my comment is a tangent, not really directly relevant:
I'm confused by the ownership semantics here. I wonder what's up with this code in soup_session_send_async():
item = soup_session_append_queue_item (session, msg, TRUE, cancellable);
// ...
item->task = g_task_new (session, item->cancellable, callback, user_data);
// ...
g_task_set_task_data (item->task, item, (GDestroyNotify) soup_message_queue_item_unref);
Now there's a circular reference between the GTask and the SoupMessageQueueItem, each of which owns the other. That seems weird. It doesn't directly explain this bug, but maybe it's related. I see it usually should not be a problem in practice, because I see the cycle normally gets broken in async_send_request_return_result(), but maybe something is wrong somewhere else. For an example of why this pattern is fragile, look at async_send_request_return_result() in soup-session.c and observe that this function can no longer safely use the SoupMessageQueueItem after it unrefs the GTask, but this is very subtle and easy to miss. (The function looks completely fine currently, but it would be easy to introduce a bug by mistake in the future.)
Unfortunately I fail to see where is the bug.
(In reply to Claudio Saavedra from comment #3)
> If you add that to deployed devices you risk having more crashes for
> unrelated reasons. Of course we would appreciate knowing if there are other
> things causing critical warnings but beware of the impact it might have for
> your deployments.
(P.S. Claudio's warning is correct and fair, but I recommend running with fatal criticals in production anyway, unless you just don't care about security or correctness. You really don't want to proceed past a use after free error, especially not in the unsandboxed network process, and both of your backtraces indicate this is happening.)
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240915/09f9237f/attachment-0001.htm>
More information about the webkit-unassigned
mailing list