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.
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
sideline thread has no chance to clean up #297
Comments
From bruen...@google.com on October 02, 2014 10:55:17 Labels: GoodContrib |
…exit We split the synch-all threads operation into two synch operations: - pre-exit synch: synchronize all app threads and ignore client threads - post-exit synch: synchronize all threads. The pre-exit synch is called before all client thread exit and process exit events. The post-exit synch is called after all the client exit events. By doing so, the sideline client thread could have a chance to perform graceful exit from the process exit event. Fixes #297
We split the synch-all threads operation into two synch operations: pre-exit synch: synchronize all app threads and ignore client threads post-exit synch: synchronize all threads. The pre-exit synch is called before all client thread exit and process exit events. The post-exit synch is called after all the client exit events. By doing so, the sideline client thread could have a chance to perform graceful exit from the process exit event. Fixes #297
We split the synch-all threads operation into two synch operations: pre-exit synch: synchronize all app threads and ignore client threads post-exit synch: synchronize all threads. The pre-exit synch is called before all client thread exit and process exit events. The post-exit synch is called after all the client exit events. By doing so, the sideline client thread could have a chance to perform graceful exit from the process exit event. Fixes #297
…on on Unix We split the synch-all threads operation into two synch operations: - pre-exit synch: synchronize all app threads and ignore client threads - post-exit synch: synchronize all threads. The pre-exit synch is called before all client thread exit and process exit events. The post-exit synch is called after all the client exit events. By doing so, the sideline client thread could have a chance to perform graceful exit from the process exit event. Fixes #297
…ion on Unix We split the synch-all threads operation into two synch operations: - pre-exit synch: synchronize all app threads and ignore client sideline threads - post-exit synch: synchronize all threads. The pre-exit synch is called before all app thread exit and process exit events. The post-exit synch is called after all the app exit events. By doing so, the sideline thread could be notified and have a chance to exit gracefully before the app process exit event. Fixes #297
Reopen this issue. If we delay the client thread exit and the client thread exit on the first synch-all, there could be a racy condition and the threads array may held stale pointer, and a SIGSEGV may occur. |
This Travis failure may be relevant: https://travis-ci.org/DynamoRIO/dynamorio/jobs/224281671 |
Hmm, very likely.
It looks like there are still racy situations on the detach.
…On Fri, Apr 21, 2017 at 6:47 AM, Edmund Grimley Evans < ***@***.***> wrote:
This Travis failure may be relevant: https://travis-ci.org/
DynamoRIO/dynamorio/jobs/224281671
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#297 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABkcDFNcyNHJ8qhcgDYI-VRG-eQXgHMRks5ryIlPgaJpZM4DBlYN>
.
|
A hang:
In GDB
So it is likely that a thread is killed while holding a lock,and the main thread hangs while trying to acquire that lock. |
However, this happens in |
Is it possible that in the first synch-all operation, although we did not terminate the thread, we somehow messed up their state? Or the exited (app/client?) thread exited without cleanup? I have seen 3 times similar hangs on the same lock, the other thread exit should have something to do with this lock.
|
From derek.br...@gmail.com on April 23, 2010 14:49:38
In debug build DR synchs + terminates our sideline thread prior to calling
our exit event so we have no chance to clean up its memory. DR then
asserts about leaks if the sideline thread had thread-local memory. DR
either needs to call the client exit event even sooner, before the
synchall, or should add support for a sideline exit routine.
Original issue: http://code.google.com/p/dynamorio/issues/detail?id=297
The text was updated successfully, but these errors were encountered: