Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dynamorio
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,467
    • Issues 1,467
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 44
    • Merge requests 44
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • DynamoRIO
  • dynamorio
  • Issues
  • #2600
Closed
Open
Issue created Aug 08, 2017 by Derek Bruening@derekbrueningContributor

CRASH from race between detach and a new thread

Detach on UNIX has a race where a new thread can have been created but not yet been added to the DR thread list at the point where detach does its synchall. The new thread will wait on thread_initexit_lock while detach proceeds and finishes. The new thread is on the dstack, and will proceed to use other resources, after detach has freed them.

Windows has a partial solution to this via its init_apc_go_native flags but technically still has a race window.

Trying to solve this once the child is created is complex and seems to require extra synch steps. I'm proposing a solution that is folded into the synchall process using a count parallel to the existing exiting_thread_count.

Assignee
Assign to
Time tracking