Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
G
GLib
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 923
    • Issues 923
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 52
    • Merge Requests 52
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GNOME
  • GLib
  • Issues
  • #1608

Closed
Open
Opened Nov 27, 2018 by Debarshi Ray@debarshirDeveloper

Cancellation might not be asynchronous under certain circumstances

I made these changes to gnome-online-accounts to simplify the code by exploiting the fact that cancellation of messages with the non-deprecated SoupSession is meant to be asynchronous:

  • commit 43ac806d01150ae8
  • commit 730e84acd8efe09e

The soup_session_abort and soup_session_cancel_message documentation says that the response callback for the cancelled messages will be called in the next iteration of the main loop after the cancelling API has returned.

In the case of gnome-online-accounts:

  • soup_session_abort is called in response to GCancellable::cancelled due to the user cancelling the enveloping asynchronous operation
  • the response callback frees the task data of the asynchronous operation which leads to g_cancellable_disconnect.

If soup_session_abort doesn't invoke the response callback asynchronously, then the code will deadlock because one cannot disconnect from a GCancellable from its GCancellable::cancelled handler, and the above gnome-online-accounts changes would not work.

While testing those changes, I found a way to trigger a deadlock. The backtrace looked like this:

  • g_cancellable_disconnect()
  • ews_client_autodiscover_data_free()
  • ews_client_autodiscover_response_cb()
  • ...
  • soup_session_abort()
  • ...
  • g_cancellable_cancel()

Sadly, now that I installed all the debug symbols, I have lost my magic powers to win the necessary races to trigger the deadlock. I believe it could be because of some local DNS cache, so hopefully I will be successful in the near future.

I have libsoup-2.64.2-1.fc29.x86_64.

Here is some documentation on how to play with gnome-online-accounts.

Edited Nov 27, 2018 by Debarshi Ray
Assignee
Assign to
2.60
Milestone
2.60 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: GNOME/glib#1608