Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • gtk gtk
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,430
    • Issues 1,430
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 243
    • Merge requests 243
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GNOME
  • gtkgtk
  • Issues
  • #979

Closed
Open
Created Nov 28, 2017 by Bugzilla@bugzilla-migration💬Reporter

Thread safety issue in gtk_application_impl_dbus_startup

Submitted by Michael Catanzaro @mcatanzaro

Link to original bug (#790963)

Description

gtk_application_impl_dbus_startup() calls g_unsetenv(). Here be dragons. As per the documentation of g_unsetenv(), and experience (e.g. bug #754951), this will explode randomly. g_unsetenv() may only be used before the first secondary thread is created, but GApplication starts working with GDBusConnection at GApplication register time, before GApplication startup, and certainly well before GtkApplication's startup.

This will be difficult to fix. One option is to document that the application must not create any threads before calling g_application_run(), and hope that applications get that right (they will not). Then store the desktop ID as global state way earlier than startup. I think GtkApplication class init would be a "good" place, since it's class data and not instance data. Alternatively, this could be done using a library constructor, which would make it very heard for applications to create a thread too soon, except then we'd have to leave Windows broken.

Another option would be to give up on unsetting the environment variable, and modify g_spawn() to always pass a custom envp to the child process with it removed. That would work so long as a GApplication always uses g_spawn() when spawning another GApplication. Eh.

Version: 3.22.x

Assignee
Assign to
Time tracking