You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The methodology of running finalize at oneprof DLL unload on windows is fundamentally broken. It assumes access to the L0 runtime library, but microsoft explicitly warns against any other DLL dependency at exit. It regularly causes a segfault.
I've tried various dll hacks to attempt to work around it, but ultimately I think we will need to do finalize when the CL/L0 context is destroyed via layer intercept when we know the DLL is still loaded.
If the process is terminating (the lpvReserved parameter is non-NULL), all threads in the process except the current thread either have exited already or have been explicitly terminated by a call to the ExitProcess function, which might leave some process resources such as heaps in an inconsistent state. In this case, it is not safe for the DLL to clean up the resources. Instead, the DLL should allow the operating system to reclaim the memory.
In case of process termination, little finalization can be done since heap may be in inconsistent state and other DLLs dependencies already unloaded.
The methodology of running finalize at oneprof DLL unload on windows is fundamentally broken. It assumes access to the L0 runtime library, but microsoft explicitly warns against any other DLL dependency at exit. It regularly causes a segfault.
I've tried various dll hacks to attempt to work around it, but ultimately I think we will need to do finalize when the CL/L0 context is destroyed via layer intercept when we know the DLL is still loaded.
There are also other issues with deconstructors during DLL unload such as https://github.com/intel/pti-gpu/blob/master/tools/oneprof/metric_streamer_collector.h#L88 which causes fault as well when the L0 driver is already unloaded.
The text was updated successfully, but these errors were encountered: