OSX Support #3
Merged
OSX Support #3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…pples LLDB.framework
mikem8361
pushed a commit
that referenced
this pull request
Aug 1, 2015
…p where the system ids (TIDs) are wrong.
First find the managed thread os id is:
(lldb) sos Threads
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
1 1 3787 00000000006547F8 20220 Preemptive 00007FFFCC0145D0:00007FFFCC015FD0 00000000006357F8 0 Ukn
6 2 3790 0000000000678FB8 21220 Preemptive 0000000000000000:0000000000000000 00000000006357F8 0 Ukn (Finalizer)
(lldb) thread list
Process 0 stopped
* thread #1: tid = 0x0000, 0x00007f01fe64d267 libc.so.6`__GI_raise(sig=6) + 55 at raise.c:55, name = 'corerun', stop reason = signal SIGABRT
thread #2: tid = 0x0001, 0x00007f01fe7138dd libc.so.6, stop reason = signal SIGABRT
thread #3: tid = 0x0002, 0x00007f01fd27dda0 libpthread.so.0`__pthread_cond_wait + 192, stop reason = signal SIGABRT
thread #4: tid = 0x0003, 0x00007f01fd27e149 libpthread.so.0`__pthread_cond_timedwait + 297, stop reason = signal SIGABRT
thread #5: tid = 0x0004, 0x00007f01fe70f28d libc.so.6, stop reason = signal SIGABRT
thread dotnet#6: tid = 0x0005, 0x00007f01fe70f49d libc.so.6, stop reason = signal SIGABRT
Then use the new command "setsostid" to set the current thread using the "OSID" from above:
(lldb) setsostid 3790 6
Set sos thread os id to 0x3790 which maps to lldb thread index 6
Now ClrStack should dump that managed thread:
(lldb) sos ClrStack
To undo the affect of this command:
(lldb) setsostid
Added setclrpath command that allows the path that sos/dac/dbi are loaded from to be changes instead of using
the coreclr path. This may be needed if loading a core dump and the debugger binaries are in a different directory
that what the dump has for coreclr's path.
mikem8361
pushed a commit
that referenced
this pull request
May 22, 2017
This api was approved here: https://github.com/dotnet/corefx/issues/5884 and is a necessary step to fixing the System.Dynamic.Runtime.Tests failure: https://github.com/dotnet/corefx/issues/19895 which is caused by Microsoft.CSharp trying to do the impossible and emulate this api without GetMetadataToken() support. This approach opts for the most straightforward and efficient implementation without any special-casing for weird situations (this is also what Microsoft.CSharp implements today as well as what someone else trying to trampoline members across generic instantaitions is like to do.) This results in the following behavior for these corner cases. With the possible exception of #3, I think they are tolerable enough to accept and codify: 1. "other" implemented by an entirely different Reflection provider than "this". Behavior: returns false without invoking any methods on the "other" Member. To change it to throw an ArgumentException would mean extra cast checks against the 6 possible Runtime types (or having said RuntimeTypes implement a sentinel interface.) Given that HasSameMetadataDefinitionAs() is a "looser cousin of Equals()" and "Equals()" doesn't throw for objects from a different universe, this seems reasonable. 2. Arrays, ByRefs, Pointers and Types from GetTypeFromCLSID() Behavior: Arrays, ByRefs, Pointers all return token 0x0600000 and so they'll return "true" wrt to each other (provided both types are implemented by the same provider.) CLSID types all return the typedef of __ComObject so they'll return "true" wrt to each other. The constructor exposed by CLSID types all return the typedef of some constructor on __ComObject so they'll return "true" wrt to each other. I do not think these are interesting cases that merit special handling. These types will never appear in an enumeration of the members of a type. (The fact that Reflection surfaces them in objects that are assignable to MemberInfo is a structural flaw in Reflection's object model.) 3. Synthesized constructors and methods on array types. Behavior: These methods all return 0x06000000 as a token so the constructors will all compare true wrt each other, and likewise with the methods. This is a bit crummy though it's not clear what the "right" policy should look like. I could be persuaded to throw NotSupported for these, to leave the possibility open for a better story later. On the other hand, I wouldn't demand it either.
mikem8361
pushed a commit
that referenced
this pull request
Jun 22, 2018
1. Computing GC roots is a relatively slow operation, and doing it for every state machine object found in a large heap can be time consuming. Making it opt-in with -roots command-line flag.
2. Added -waiting command-line flag. DumpAsync will now retrieve the <>1__state field from the StateMachine, and if -waiting is specified, it'll filter down to state machines that have a state value >= 0, meaning the state machines are waiting at an await point. For example, given this program:
```C#
using System.Threading.Tasks;
class Program
{
static async Task Main() { await MethodA(0); await MethodA(int.MaxValue); }
static async Task MethodA(int delay) => await MethodB(delay);
static async Task MethodB(int delay) { await Task.Yield(); await Task.Delay(delay); }
}
```
using `!DumpAsync` outputs:
```
Address MT Size Name
#0
0000026848693438 00007ff88ea35e58 120 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<MethodB>d__2, test]]
StateMachine: Program+<MethodB>d__2 (struct)
MT Field Offset Type VT Attr Value Name
00007ff8e9bc4bc0 4000008 0 System.Int32 1 instance -2 <>1__state
00007ff8e9bd82f8 4000009 8 ...TaskMethodBuilder 1 instance 0000026848693490 <>t__builder
00007ff8e9bc4bc0 400000a 4 System.Int32 1 instance 0 delay
00007ff8e9bee4d0 400000b 10 ...able+YieldAwaiter 1 instance 0000026848693498 <>u__1
00007ff8e9bcead0 400000c 18 ...vices.TaskAwaiter 1 instance 00000268486934a0 <>u__2
Continuation: 00000268486934b0 (System.Object)
#1
0000026848693e68 00007ff88ea36cc8 112 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<MethodA>d__1, test]]
StateMachine: Program+<MethodA>d__1 (struct)
MT Field Offset Type VT Attr Value Name
00007ff8e9bc4bc0 4000004 0 System.Int32 1 instance -2 <>1__state
00007ff8e9bd82f8 4000005 8 ...TaskMethodBuilder 1 instance 0000026848693ec0 <>t__builder
00007ff8e9bc4bc0 4000006 4 System.Int32 1 instance 0 delay
00007ff8e9bcead0 4000007 10 ...vices.TaskAwaiter 1 instance 0000026848693ec8 <>u__1
Continuation: 00000268486934b0 (System.Object)
#2
0000026848693ed8 00007ff88ea37188 112 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<Main>d__0, test]]
StateMachine: Program+<Main>d__0 (struct)
MT Field Offset Type VT Attr Value Name
00007ff8e9bc4bc0 4000001 0 System.Int32 1 instance 1 <>1__state
00007ff8e9bd82f8 4000002 8 ...TaskMethodBuilder 1 instance 0000026848693f30 <>t__builder
00007ff8e9bcead0 4000003 10 ...vices.TaskAwaiter 1 instance 0000026848693f38 <>u__1
Continuation: 0000026848693f48 (System.Threading.Tasks.Task+SetOnInvokeMres)
#3
0000026848695d30 00007ff88ea35e58 120 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<MethodB>d__2, test]]
StateMachine: Program+<MethodB>d__2 (struct)
MT Field Offset Type VT Attr Value Name
00007ff8e9bc4bc0 4000008 0 System.Int32 1 instance 1 <>1__state
00007ff8e9bd82f8 4000009 8 ...TaskMethodBuilder 1 instance 0000026848695d88 <>t__builder
00007ff8e9bc4bc0 400000a 4 System.Int32 1 instance 2147483647 delay
00007ff8e9bee4d0 400000b 10 ...able+YieldAwaiter 1 instance 0000026848695d90 <>u__1
00007ff8e9bcead0 400000c 18 ...vices.TaskAwaiter 1 instance 0000026848695d98 <>u__2
Continuation: 0000026848695dd0 (System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<MethodA>d__1, test]])
#4
0000026848695dd0 00007ff88ea36cc8 112 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<MethodA>d__1, test]]
StateMachine: Program+<MethodA>d__1 (struct)
MT Field Offset Type VT Attr Value Name
00007ff8e9bc4bc0 4000004 0 System.Int32 1 instance 0 <>1__state
00007ff8e9bd82f8 4000005 8 ...TaskMethodBuilder 1 instance 0000026848695e28 <>t__builder
00007ff8e9bc4bc0 4000006 4 System.Int32 1 instance 2147483647 delay
00007ff8e9bcead0 4000007 10 ...vices.TaskAwaiter 1 instance 0000026848695e30 <>u__1
Continuation: 0000026848693ed8 (System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<Main>d__0, test]])
Found 5 state machines.
```
while using `!DumpAsync -waiting` outputs only:
```
Address MT Size Name
#0
0000026848693ed8 00007ff88ea37188 112 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<Main>d__0, test]]
StateMachine: Program+<Main>d__0 (struct)
MT Field Offset Type VT Attr Value Name
00007ff8e9bc4bc0 4000001 0 System.Int32 1 instance 1 <>1__state
00007ff8e9bd82f8 4000002 8 ...TaskMethodBuilder 1 instance 0000026848693f30 <>t__builder
00007ff8e9bcead0 4000003 10 ...vices.TaskAwaiter 1 instance 0000026848693f38 <>u__1
Continuation: 0000026848693f48 (System.Threading.Tasks.Task+SetOnInvokeMres)
#1
0000026848695d30 00007ff88ea35e58 120 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<MethodB>d__2, test]]
StateMachine: Program+<MethodB>d__2 (struct)
MT Field Offset Type VT Attr Value Name
00007ff8e9bc4bc0 4000008 0 System.Int32 1 instance 1 <>1__state
00007ff8e9bd82f8 4000009 8 ...TaskMethodBuilder 1 instance 0000026848695d88 <>t__builder
00007ff8e9bc4bc0 400000a 4 System.Int32 1 instance 2147483647 delay
00007ff8e9bee4d0 400000b 10 ...able+YieldAwaiter 1 instance 0000026848695d90 <>u__1
00007ff8e9bcead0 400000c 18 ...vices.TaskAwaiter 1 instance 0000026848695d98 <>u__2
Continuation: 0000026848695dd0 (System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<MethodA>d__1, test]])
#2
0000026848695dd0 00007ff88ea36cc8 112 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<MethodA>d__1, test]]
StateMachine: Program+<MethodA>d__1 (struct)
MT Field Offset Type VT Attr Value Name
00007ff8e9bc4bc0 4000004 0 System.Int32 1 instance 0 <>1__state
00007ff8e9bd82f8 4000005 8 ...TaskMethodBuilder 1 instance 0000026848695e28 <>t__builder
00007ff8e9bc4bc0 4000006 4 System.Int32 1 instance 2147483647 delay
00007ff8e9bcead0 4000007 10 ...vices.TaskAwaiter 1 instance 0000026848695e30 <>u__1
Continuation: 0000026848693ed8 (System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Threading.Tasks.VoidTaskResult, System.Private.CoreLib],[Program+<Main>d__0, test]])
Found 3 state machines.
```
skipping the two state machines that have a `<>1__state` field value of -2 (meaning it's completed). Note that this change has the somewhat unfortunate impact of taking a dependency on what's effectively an implementation detail of Roslyn, but the value the filtering provides is deemed to be worth it. This design is unlikely to change in the future, and as with other diagnostic/debugging features that rely on such details, it can be updated if Roslyn ever changes its scheme. In the meantime, the code will output a warning message if it can't find the state field.
3. If a state machine is found to have 0 roots but also to have a <>1__state value >= 0, that suggests it was dropped without having been completed, which is likely a sign of an application bug. The command now prints out an information message to highlight that state. For example, this program:
```C#
using System;
using System.Threading.Tasks;
class Program
{
static void Main()
{
Task.Run(async () => await new TaskCompletionSource<bool>().Task);
Console.ReadLine();
}
}
```
when processed with `!DumpAsync -roots` results in:
```
Address MT Size Name
#0
0000020787fb5b30 00007ff88ea1afe8 112 System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1+AsyncStateMachineBox`1[[System.Boolean, System.Private.CoreLib],[Program+<>c+<<Main>b__0_0>d, test]]
StateMachine: Program+<>c+<<Main>b__0_0>d (struct)
MT Field Offset Type VT Attr Value Name
00007ff8e9bc4bc0 4000003 0 System.Int32 1 instance 0 <>1__state
00007ff8e9bd0b88 4000004 8 ...Private.CoreLib]] 1 instance 0000020787fb5b88 <>t__builder
00007ff8e9bffd58 4000005 10 ...Private.CoreLib]] 1 instance 0000020787fb5b90 <>u__1
Continuation: 0000020787fb3fc8 (System.Threading.Tasks.UnwrapPromise`1[[System.Boolean, System.Private.CoreLib]])
GC roots:
Incomplete state machine (<>1__state == 0) with 0 roots.
Found 1 state machines.
```
mikem8361
pushed a commit
that referenced
this pull request
Oct 23, 2019
* find src/jit -type f -exec sed -i -e 's/gtLclVarCommon\./AsLclVarCommon()\./g' {} \;
gtLclVarCommon
* Format patch
* Format patch
* Format patch #3
* Remove redundant /
mikem8361
pushed a commit
that referenced
this pull request
Nov 17, 2019
This change contains the remaining fixes I made while digging through the PR run in the runtime repo: 1) Some more repo-relative vs. coreclr-relative repo adjustments reflecting the migration process; 2) Make sure that XunitTestBinBase always ends with a directory separator, otherwise my recent fix for Common folder exclusion doesn't work; 3) Opportunistically shorten project names of two native interop test components - as the project name is repeated about 3-4 times in some intermediate paths, it quickly exceeds the standard Windows path length limit. Please note there's no functional change in the test. Thanks Tomas
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey, refactored your cmake stuff a little so that it can at least build and link on OSX.
Using an lldb checkout to get the public API, and Xcode's private framework can be achieved like so:
LLDB_INCLUDE_DIR=/Users/plasma/Work/lldb/include
LLDB_LIB_DIR=/Applications/Xcode.app/Contents/SharedFrameworks
*Third time is a charm