CoreCLR profiler check exists of native thread leading runtime crash?

[AlexeiNaabal]

Greetings coreclr devs.

This question is about CoreCLR profiler components and native thread that created outside coreclr runtime.

Right now we are trying to add custom profiler to an embedded coreclr runtime, and it works as expected when under single thread mode, but meets some thread exits check failure under multi thread mode.

The multi thread scenario is like:
We launched the embedded coreclr runtime with hostfxr api, then invoke some native function to feed native async task into a native task producer with managed function callback pointer for task consumer to invoke when task finished. When interacting with the task producer, we are under main thread so everything works fine.

The producer create native thread that the coreclr runtime is not aware of, like async loading resources on native code, once load done, pass the loaded resource to the managed function callback that hooked before. That means we have a native thread invoking managed code, it works as expected too.

Then we enable a coreclr profiler that implemented the ICorProfiler interface, and redo the process above, it triggers the runtime enter ProfileEnter, where there are thread valid check in proftoeeinterfaceimpl.cpp, like

GCX_COOP_THREAD_EXISTS(GET_THREAD());
// where expanded with
inline Thread* GetThread()
{
    Thread* pThread = gCurrentThreadInfo.m_pThread;
    _ASSERTE(pThread);  // pThread will be invalid as currently we are in the native thread that created outside
    return pThread;
}

and the assert will fail as the pThread is invalid value like 0xc0000005. By looking at the Thread info in visual studio, we confirm that current thread is a host's native thread.

We would like to know if coreclr exposes api to register or attach the native thread to runtime before the ProfileEnter stage, to have the gCurrentThreadInfo contains necessary thread info representing the thread, other than invalid value?

[AlexeiNaabal]

@janvorli Sorry for bothering you here, just saw you committed this thread check. The ThreadLocalInfo gCurrentThreadInfo has all it's member value 0 when failing the assert, seems this object is not assigned, is that by design with such procedural?

Edit:
here at

runtime/src/coreclr/vm/proftoeeinterfaceimpl.cpp

Line 10735 in 9bcd3e7

if (GetThreadNULLOk() == NULL)

, the runtime setup the thread if it is not yet gathered by runtime, while before this setup we have thread valid check with GET_THREAD() if current thread is not yet recognized at

runtime/src/coreclr/vm/proftoeeinterfaceimpl.cpp

Line 10729 in 9bcd3e7

GCX_COOP_THREAD_EXISTS(GET_THREAD());

, the runtime will throw and exit if the check assert failed, it seems the setup in L10735 might not get invoked? or maybe we missed some profiler config that can bypass the thread check?

[AlexeiNaabal]

@huoyaoyuan sorry for bothering you here too, could you please label this discussion and help me inform the relevant developer?

[huoyaoyuan]

The profiler API is owned by diagnostics. Maybe @tommcdon can help to triage this.

[AlexeiNaabal]

Appreciate your help

[janvorli]

@AlexeiNaabal I've looked into it and found an old issue that discusses this problem: #68760.

[AlexeiNaabal]

The work around in the old issue seems suggesting cache the methods that invoked by the native thread, when later rebuild the callstack, remove them,

while the issue we are facing is the profiler failed the assert inside GET_THREAD() in a rather early stage of profile stage ProfileEnter, and causing the runtime exit, by the time we neither have the info of the managed function, nor we can stop the runtime from exit,

thus the work around might not applicable, or did I miss existing solution in that discussion?

[janvorli]

Ah, you are right, the way it happens you don't have any control over it and my change from 2 years ago has actually caused this issue.

It seems that while I've added the GCX_COOP into the body after ensuring that the runtime has registered the thread, I've forgotten to remove the GCX_COOP_THREAD_EXISTS(GET_THREAD()); from the header of the ProfileEnter.

[janvorli]

Let me create an issue from this discussion and fix it.

[AlexeiNaabal]

Thanks for your help!

[janvorli]

No problem!