Identification of JIT generated functions by their address

[yegor-pelykh]

I use the Profiler API to get a mixed mode call stack.
The problem is that for some of the native frames of the resulting stack (related to the managed -> unmanaged transition, hidden behind the DllImport) are completely unknown - it is impossible to get symbolic information for them, even just the module to which the return address belongs.

GetFunctionFromIP for the address of this frame returns E_FAIL, which means that the function is unmanaged.

As I understand, this is a JIT generated piece of code.
But how can I know this for sure, to determine this for any other such piece of code from any call stack?
And I'd like to get the module to which this piece of code belongs, as well as some text description (let's say the "name" of the function).

Please, could you help me?

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[tommcdon]

@mdh1418

[mdh1418]

Hi @yegor-pelykh, just to clarify, is what you're seeing in your callstack a bunch of frames corresponding to managed code, and then some frames that dont seem to have any useful information besides an address?
Perhaps something like this?

00f7e9bc 6c73d1af System_Private_CoreLib!System.UInt64 System.Diagnostics.Tracing.EventPipeInternal::Enable(System.String, System.Diagnostics.Tracing.EventPipeSerializationFormat, System.UInt32, System.Diagnostics.Tracing.EventPipeProviderConfiguration[])$##6008E81+0xfe
00f7ea80 6c73d036 System_Private_CoreLib!System.Diagnostics.Tracing.EventPipeEventDispatcher::CommitDispatchConfiguration()$##6008E99+0x13f
00f7eab0 6c74c6dd System_Private_CoreLib!System.Diagnostics.Tracing.EventPipeEventDispatcher::SendCommand(System.Diagnostics.Tracing.EventListener, System.Diagnostics.Tracing.EventCommand, System.Boolean, System.Diagnostics.Tracing.EventLevel, System.Diagnostics.Tracing.EventKeywords)$##6008E98+0xc6
00f7ead4 6c74cbf3 System_Private_CoreLib!System.Diagnostics.Tracing.EventListener::DisableEvents(System.Diagnostics.Tracing.EventSource)$##6008F9E+0x4d
00f7eb04 6c74cd07 System_Private_CoreLib!System.Diagnostics.Tracing.EventListener::CallDisableEventsIfNecessary(System.Diagnostics.Tracing.EventDispatcher, System.Diagnostics.Tracing.EventSource)$##6008FA4+0x53
00f7eb50 6c74c584 System_Private_CoreLib!System.Diagnostics.Tracing.EventListener::RemoveReferencesToListenerInEventSources(System.Diagnostics.Tracing.EventListener)$##6008FA5+0xb7
00f7eb7c 08d17ba7 System_Private_CoreLib!System.Diagnostics.Tracing.EventListener::Dispose()$##6008F9A+0x94
00f7ebb4 08d11db4 0x8d17ba7
00f7ec30 08d1183a 0x8d11db4
00f7ec4c 6f29dd05 0x8d1183a

If that is the case, then I do agree that its missing symbol information, but I don't know if there is any other telltale sign to figure out the source of the frames with missing symbol information.

Are you building everything in debug configuration? How are you grabbing the callstack? I don't really know if there is any other way to sleuth those frames besides ensuring that you're building with debug configuration to generate symbols and that whichever thing you're using to grab callstacks loads those symbols.

[yegor-pelykh]

Hi @mdh1418. Thanks for the answer!

Hi @yegor-pelykh, just to clarify, is what you're seeing in your callstack a bunch of frames corresponding to managed code, and then some frames that dont seem to have any useful information besides an address? Perhaps something like this?

00f7e9bc 6c73d1af System_Private_CoreLib!System.UInt64 System.Diagnostics.Tracing.EventPipeInternal::Enable(System.String, System.Diagnostics.Tracing.EventPipeSerializationFormat, System.UInt32, System.Diagnostics.Tracing.EventPipeProviderConfiguration[])$##6008E81+0xfe
00f7ea80 6c73d036 System_Private_CoreLib!System.Diagnostics.Tracing.EventPipeEventDispatcher::CommitDispatchConfiguration()$##6008E99+0x13f
00f7eab0 6c74c6dd System_Private_CoreLib!System.Diagnostics.Tracing.EventPipeEventDispatcher::SendCommand(System.Diagnostics.Tracing.EventListener, System.Diagnostics.Tracing.EventCommand, System.Boolean, System.Diagnostics.Tracing.EventLevel, System.Diagnostics.Tracing.EventKeywords)$##6008E98+0xc6
00f7ead4 6c74cbf3 System_Private_CoreLib!System.Diagnostics.Tracing.EventListener::DisableEvents(System.Diagnostics.Tracing.EventSource)$##6008F9E+0x4d
00f7eb04 6c74cd07 System_Private_CoreLib!System.Diagnostics.Tracing.EventListener::CallDisableEventsIfNecessary(System.Diagnostics.Tracing.EventDispatcher, System.Diagnostics.Tracing.EventSource)$##6008FA4+0x53
00f7eb50 6c74c584 System_Private_CoreLib!System.Diagnostics.Tracing.EventListener::RemoveReferencesToListenerInEventSources(System.Diagnostics.Tracing.EventListener)$##6008FA5+0xb7
00f7eb7c 08d17ba7 System_Private_CoreLib!System.Diagnostics.Tracing.EventListener::Dispose()$##6008F9A+0x94
00f7ebb4 08d11db4 0x8d17ba7
00f7ec30 08d1183a 0x8d11db4
00f7ec4c 6f29dd05 0x8d1183a

That's exactly what I'm talking about.

This is a debug configuration. Symbols were also initialized. There are no recognition problems with any other frames.
And the problem here is not only in symbols. It is also impossible to know the module in whose space the address is located (and it should be possible to recognize it even independently of the symbols).

What is even more interesting is that if you look at these same addresses from under WinDbg with the SOS add-on, these addresses are recognized as IL Stub, and, it seems, belong to the main running module of the application. And this is strange to me, since SOS can understand which module they belong to, and also name the symbols.

Could you look at such addresses in more detail, especially how this is implemented in SOS, and also make some changes to the Profiler API capabilities to be able to determine the info for these addresses?

Please.

[mdh1418]

Hi @yegor-pelykh, I'm noticing that GetFunctionFromIP invokes GetFunctionFromIPInternal with failOnNoMetadata=true. Since IL Stubs will not have metadata, maybe GetFunctionFromIP3

runtime/src/coreclr/vm/proftoeeinterfaceimpl.cpp

Line 6233 in 9a31a5b

HRESULT ProfToEEInterfaceImpl::GetFunctionFromIP3(LPCBYTE ip, FunctionID * pFunctionId, ReJITID * pReJitId)

will work.

Could you elaborate on how you're grabbing the mixed mode call stack with a profiler and do you mainly need the IL Stubs information to trace back to unmanaged code?

[dotnet-policy-service]

This issue has been marked needs-author-action and may be missing some important information.

[dotnet-policy-service]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.