{"action":"closed","issue":{"url":"https://api.github.com/repos/dyninst/dyninst/issues/208","repository_url":"https://api.github.com/repos/dyninst/dyninst","labels_url":"https://api.github.com/repos/dyninst/dyninst/issues/208/labels{/name}","comments_url":"https://api.github.com/repos/dyninst/dyninst/issues/208/comments","events_url":"https://api.github.com/repos/dyninst/dyninst/issues/208/events","html_url":"https://github.com/dyninst/dyninst/issues/208","id":184049239,"number":208,"title":"Race conditions with transient threads","user":{"login":"cuviper","id":36186,"avatar_url":"https://avatars.githubusercontent.com/u/36186?v=3","gravatar_id":"","url":"https://api.github.com/users/cuviper","html_url":"https://github.com/cuviper","followers_url":"https://api.github.com/users/cuviper/followers","following_url":"https://api.github.com/users/cuviper/following{/other_user}","gists_url":"https://api.github.com/users/cuviper/gists{/gist_id}","starred_url":"https://api.github.com/users/cuviper/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cuviper/subscriptions","organizations_url":"https://api.github.com/users/cuviper/orgs","repos_url":"https://api.github.com/users/cuviper/repos","events_url":"https://api.github.com/users/cuviper/events{/privacy}","received_events_url":"https://api.github.com/users/cuviper/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/dyninst/dyninst/milestones/5","html_url":"https://github.com/dyninst/dyninst/milestones/Release%209.3.0","labels_url":"https://api.github.com/repos/dyninst/dyninst/milestones/5/labels","id":1881423,"number":5,"title":"Release 9.3.0","description":"","creator":{"login":"jdetter","id":4099508,"avatar_url":"https://avatars.githubusercontent.com/u/4099508?v=3","gravatar_id":"","url":"https://api.github.com/users/jdetter","html_url":"https://github.com/jdetter","followers_url":"https://api.github.com/users/jdetter/followers","following_url":"https://api.github.com/users/jdetter/following{/other_user}","gists_url":"https://api.github.com/users/jdetter/gists{/gist_id}","starred_url":"https://api.github.com/users/jdetter/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jdetter/subscriptions","organizations_url":"https://api.github.com/users/jdetter/orgs","repos_url":"https://api.github.com/users/jdetter/repos","events_url":"https://api.github.com/users/jdetter/events{/privacy}","received_events_url":"https://api.github.com/users/jdetter/received_events","type":"User","site_admin":false},"open_issues":6,"closed_issues":11,"state":"open","created_at":"2016-07-13T17:10:19Z","updated_at":"2016-12-01T19:32:52Z","due_on":null,"closed_at":null},"comments":11,"created_at":"2016-10-19T19:12:52Z","updated_at":"2016-12-01T19:32:52Z","closed_at":"2016-12-01T19:32:52Z","body":"I've been staring at [rhbz1373197](https://bugzilla.redhat.com/show_bug.cgi?id=1373197) too long -- time to involve you folks here.  (I probably should have just filed this a while ago, sorry.)\n\nThe test mutator simply detaches and reattaches the target over and over.  It has a watchdog thread to make sure we're making progress.  Sometimes this watchdog triggers, indicating something stalled, and sometime the reattach just fails outright.  I've added code to write a `debug-proccontrol` file too.\n\nThe test mutatee simply spawns a thread, and that thread waits 100ms before spawning a new copy of itself.  So threads are coming and going fairly frequently, and it makes it pretty reproducible for proccontrol to race on these events while reattaching.\n\n[proccontrol-thread-race.zip](https://github.com/dyninst/dyninst/files/539952/proccontrol-thread-race.zip)\n\nRun the `thready` mutatee in the background or in a different terminal, then find its PID and run `dyninst-reattach-loop PID`.  The time to getting stuck/failure varies a lot, but it inevitably does hit one of the races eventually.\n\nBroadly speaking, the \"stuck\" case seems to consistently be that it sends a manual SIGSTOP, and never sees an event after that.  I never see this manual SIGSTOP otherwise, until we get to this bad case.  The direct \"failed\" case seems to be that it's trying to read /proc/PID/stat for a thread that already exited (known from the previous attachment?), and it bails entirely.  I'm not sure how to fix either case.\n"}}
{"actor":{"display_login":"cuviper"}}