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
  • #2728
Closed
Open
Issue created Dec 01, 2017 by Administrator@rootContributor

Slow attach times due to protecting stack/heap allocations

Created by: Carrotman42

NOTE: the following describes an incorrect solution to the problem of slow attach times. See further down for details about this issue.

During attach on Unix, the thread executing os_take_over_all_unknown_threads:

  1. obtains the thread_initexit_lock
  2. (does some other stuff)
  3. calls thread_signal to all other threads
  4. unlocks thread_initexit_lock
  5. waits on each threads' "event" one at a time until all threads are suspended

All threads obtain thread_initexit_lock during their attach logic, and I believe signaling all threads and then unlocking the lock causes contention on thread_initexit_lock. With 3000 threads in my simple repro, attaching takes 70 seconds whereas the following implementation finishes in under a second:

  1. obtains the thread_initexit_lock
  2. (does some other stuff)
  3. unlocks thread_initexit_lock
  4. for each thread: 4.1) signal that thread 4.2) wait for that thread's "event"
Assignee
Assign to
Time tracking