| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
llvm-svn: 217419
|
| |
|
|
|
|
|
|
|
|
| |
mistake in the lock acquistion in HistoryUnwind and HistoryThread.
We've got a deadlock with one use case of HistoryUnwind; I
need to figure out what lock ordering is causing this and fix
it for real.
<rdar://problem/17411904>
llvm-svn: 211541
|
| |
|
|
|
|
|
|
|
|
| |
to modify the same UnwindTable object simultaneously. Fix
HistoryThread and HistoryUnwind's mutex lock acqusition to
retain the lock for the duration of the operation instead of
releasing the temporary immediately.
<rdar://problem/17055023>
llvm-svn: 211241
|
| |
|
|
|
|
|
|
|
|
|
| |
hold a strong pointer to that extended backtrace thread in the Process
just like we do for asking a thread's extended backtrace.
Also, give extended backtrace threads an invalid ThreadIndexID number.
We'll still give them valid thread_id's. Clients who want to know the
original thread's IndexID can call GetExtendedBacktraceOriginatingIndexID().
<rdar://problem/16126034>
llvm-svn: 203088
|
|
|
Still working out some of the details of these classes but
I wanted to get the overall structure checked in.
<rdar://problem/15314068>
llvm-svn: 194245
|
