-
由 Matt Bauer 提交于
* Handle race between fork and task_for_pid On macOS a call to fork and a subsequent call to task_for_pid will race each other. This is because the macOS kernel assigns a new proc_t structure early but the new task, thread and uthread come much later. The function exec_mach_imgact in the XNU sources contains this logic. In a system under load or one with delays in fork processing (i.e. various security software), task_for_pid as currently called by Delve often returns the parent task. This can be seen by printing out the task number around line 86. In a normal system we would see three calls: -> ~/go/bin/dlv --listen=localhost:59115 --headless=true --api-version=2 --backend=native exec ./___main_go -- Task: 9731 Task: 9731 Task: 9731 API server listening at: 127.0.0.1:59115 This is the result on a system where the race is lost: -> ~/go/bin/dlv --listen=localhost:59115 --headless=true --api-version=2 --backend=native exec ./___main_go -- Task: 8707 Task: 10499 Task: 10499 could not launch process: could not get thread count In this latter case, task 8707 is the parent task. The child task of 10499 was desired and hence the error. This code change checks to make sure the returned task is not that of the parent. If it is, it retries. It's possible other macOS reported Delve issues are the result of this failed race. * proc: correct formatting
beb3e76f