Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

rank order violation when alarm arrives in deadlock code #2061

Closed
derekbruening opened this issue Nov 8, 2016 · 0 comments
Closed

rank order violation when alarm arrives in deadlock code #2061

derekbruening opened this issue Nov 8, 2016 · 0 comments
Labels
Bug-Hang OpSys-Linux

Comments

@derekbruening
Copy link
Contributor 

<rank order violation shared_itimer_lock(recursive)@third_party/dynamorio/trunk/core/unix/signal.c:1496 acquired after innermost_lock(mutex)@third_party/dynamorio/trunk/core/utils.c:223 in tid:1d767>
<press enter to continue>

innermost_lock is grabbed inside various process lock handling routines (debug-only) so an alarm that arrives there could hit this. Maybe we should check and drop the signal if this happens?

We do not expect any problems in release build.
derekbruening added a commit that referenced this issue Aug 9, 2017
@derekbruening
i#2061: fix thread exit race on attach
64ec0a4 
To handle a thread exiting on attach, adds a timeout to wait_event() and
its corresponding implementations: os_wait_event() on Windows and
ksynch_wait() on UNIX.  Uses the timeout to check whether a thread exited,
and if so, to move on.

Augments the test from #2600 to test this race.

Fixes #2061
@derekbruening derekbruening mentioned this issue Aug 9, 2017
Merged
@derekbruening derekbruening mentioned this issue Sep 11, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug-Hang OpSys-Linux
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@derekbruening