Runtime: Attach/Detach support in profiler

[ww898]

Hi there,

is there plans to enable FEATURE_PROFAPI_ATTACH_DETACH in CoreCLR? Do you have any plans? Will you did it separately on Linux and Windows?

[mfilippov]

We want to attach and detach dotTrace profiler to running .NET Core processes such as ASP .NET Core, Console Application, UWP, etc... on all supported platforms. If it possible only windows now let's do it on Windows.

[jkotas]

cc @noahfalk

[lt72]

We are working on it, on both Windows and Linux, but there is no set date yet to deliver this. It will not be in 2.1 for sure, maybe in 2.2.

[KKatsnel]

Hi,

Any updates on it? How about 3.0?

[noahfalk]

This is still something we intend to do, but I don't have a specific date or release yet where I can commit it will be done. If anyone is interested in working on it to ensure it is ready faster we're always glad for the help.

But to provide something a little more informative than that, right now we are building a generic xplat IPC channel that multiple tools could use to ask the runtime to do things. The current debugger IPC mechanism isn't very flexible because it only allows one tool to be connected whereas we've shifted our focus to Unix Domain Sockets which support multiple clients. The first use-case we wanted the new IPC mechanism for was to enable runtime telemetry and tracing streams and then the second thing we had in mind was this issue, attaching an in-proc profiler. @jorive is actively working on the first part, and although its not PR ready yet, there are some fragments of work in progress visible. Once @jorive's work is done and the IPC channel is in place, using it to initiate the load of an in-proc profiler seems like a relatively small addition.

HTH!
-Noah

[lucaspimentel]

Looks like profiler attach support on Windows was added in dotnet/coreclr#18762.

[davmason]

Windows only support was added in dotnet/coreclr#18762, yesterday I checked in dotnet/coreclr#24670 which removes the windows only attach mechanism and replaces it with one that works on windows and linux.

I am leaving this issue open for now until I get documentation on how to consume it. The short answer is to use the code I added to Microsoft.Diagnostics.Tools.RuntimeClient here https://github.com/dotnet/diagnostics/pull/274. The long answer will come as a howto guide I'll add and then post to the profiler announcement issue.

[ww898]

Hi, have just implemented attaching to CoreCLR v3.0.0.-preview5 through CreateCLRProfiling. Everything works properly at first look. I don't see any documentation for that. Could you please publish the document with correct attaching procedure in it? I am absolutely not sure that my way is correct.

And the important question: how to detect that the process with pid # has coreclr available for attach on different OS?

[davmason]

@ww898 I am in the process of creating documentation for profiler attach. I hope to have it done soon.

Unfortunately CreateCLRProfiling is being removed in Preview6 and replaced with a new attach mechanism so it will no longer be an option. The transition to the new attach mechanism should hopefully not be too much code churn.

And the important question: how to detect that the process with pid # has coreclr available for attach on different OS?

The new attach mechanism is built on the EventPipe protocol, so the process with that would be trying to attach, and then an error HR would indicate it does not support attach

[ww898]

@davmason Thanks a lot.

The important question about protocol between client and coreclr: will it be open or proprietary?

[tommcdon]

@ww898 the IPC Event Pipe protocol is documented here: https://github.com/dotnet/diagnostics/blob/master/documentation/design-docs/ipc-protocol.md. We are also planning on creating an IPC Event Pipe client library, tracked on https://github.com/dotnet/diagnostics/issues/191.

[ww898]

@tommcdon Thanks a lot. I already connected it to our code and slitely adapted it for .NET Framework 4.6.1. Unfortunately, I can't test it with preview5 because the pipe protocol is different. So, we are waiting preview6.

[noahfalk]

will it be open or proprietary?

I think this was implied by Tom's answer, but just to be certain for anyone else seeing it, that documentation isn't just internal documentation for us. We fully intend for third parties to be able to write their own implementations of the remote client and communicate with the runtime over that protocol. If our managed implementation of the client library suits your needs (once we ship it) we hope that makes many use cases easier, but if for whatever reason it does not the protocol is an open and supported option : )

[davmason]

Fixed in dotnet/coreclr#24670. Documentation for how to use it is available at https://github.com/dotnet/coreclr/blob/master/Documentation/Profiling/Profiler%20Attach%20on%20CoreCLR.md

[k15tfu]

@davmason @noahfalk A bit confused that Profiler Attach/Detach feature (i.e. FEATURE_PROFAPI_ATTACH_DETACH) is not available on macOS: https://github.com/dotnet/coreclr/blob/5558d18aafc84ecac3630ca6a31f52699cde0b66/clrdefinitions.cmake#L184.
Is it a typo, or are there actually some unresolved issues to support this?

[davmason]

@k15tfu profiling is not officially supported on macos. The fact that PROFILING_SUPPORTED is defined for anything besides linux or windows is an oversight. We only test the profiler on linux and windows, and only guarantee it will work as expected on those platforms.