Issue with XPTI subscriber detection for subprocess inheritance

[wdziurdz]

The last release introduced an issue with subprocess XPTI subscriber detection:

Process 1 (Parent Process):

1. Python test initializes and loads PTI library
2. PTI queries XPTI_SUBSCRIBERS environment variable: Result = Not Set
3. PTI registers as XPTI subscriber by setting: XPTI_SUBSCRIBERS=/path/to/libpti.so

Process 2 (Child Process via subprocess):

1. Child process inherits env from parent process including: XPTI_SUBSCRIBERS=/path/to/libpti.so (inherited)
2. Child process loads PTI library
3. PTI queries XPTI_SUBSCRIBERS environment variable: Result = Already Set
4. PTI incorrectly interprets parent's PTI subscription as foreign subscriber
5. PTI outputs warning: "Another subscriber already subscribed to Sycl runtime events..."

Root Cause

The current implementation only checks if XPTI_SUBSCRIBERS is non-empty, without difference between PTI itself and real foreign subscribers.

Current Implementation

inline std::pair<bool, bool> IsSubscriberToXPTI() {
  auto current_xpti_subscriber = utils::GetEnv("XPTI_SUBSCRIBERS");
  // and may be it is unitrace
  return {!current_xpti_subscriber.empty(),
          current_xpti_subscriber.find("unitrace") != std::string::npos};
}

Proposed Fix

inline std::pair<bool, bool> IsSubscriberToXPTI() {
  auto current_xpti_subscriber = utils::GetEnv("XPTI_SUBSCRIBERS");
  bool is_unitrace = current_xpti_subscriber.find("unitrace") != std::string::npos;

  if (current_xpti_subscriber.empty()) {
    return {false, is_unitrace};
  }
  
  // Check if the subscriber is PTI itself (not foreign for linux + win)
  if (current_xpti_subscriber.find("libpti") != std::string::npos ||
      current_xpti_subscriber.find("pti.dll") != std::string::npos) {
    return {false, is_unitrace};
  }
  
  // It's a real foreign subscriber (not PTI)
  return {true, is_unitrace};
}

Related issue : intel/intel-xpu-backend-for-triton#4998

[anmyachev]

@jfedorov could you take a look?

[jfedorov]

many thanks for investigation and suggested fix @anmyachev and @wdziurdz !
The fix makes sense - Can you polish it a little bit (e,g, have pti_lib_pattern as constant and different for Linux and Windows)
and PR it to the internal repo?
and open to me a bug (JIRA) that I need to add a test for it

[anmyachev]

The fix makes sense - Can you polish it a little bit (e,g, have pti_lib_pattern as constant and different for Linux and Windows)
and PR it to the internal repo?

Sure, but we need write access in this internal repo. Could you give it to us?

and open to me a bug (JIRA) that I need to add a test for it

I will create.