[UR][layer] Add exception sanitizer layer

[hdelan]

Add basic exception sanitizer layer that will call std::abort if an exception is thrown. This layer can be used to make sure an adapter isn't throwing, which is prohibited for a C interface. The layer can be enabled by building with the option -DUR_ENABLE_EXCEPTION_SANITIZER=ON

[pbalcer]

I suspect this was never tested :D So might be good to enable this in CI for CTS.

[hdelan]

I suspect this was never tested :D So might be good to enable this in CI for CTS.

Thanks have done so. I'm not sure what the failures are related to.

[EwanC]

LGTM, thanks for improving our code quality

[kbenzie]

So the missing part here is actually enabling the layer in the CTS environment setup, something along the lines of this:

diff --git a/test/conformance/source/environment.cpp b/test/conformance/source/environment.cpp
index 006ea09b..737d26d2 100644
--- a/test/conformance/source/environment.cpp
+++ b/test/conformance/source/environment.cpp
@@ -90,6 +90,14 @@ uur::PlatformEnvironment::PlatformEnvironment(int argc, char **argv)
             error = "Failed to enable validation layer";
             return;
         }
+#ifdef UR_ENABLE_EXCEPTION_SANITIZER
+        if (urLoaderConfigEnableLayer(config, "UR_LAYER_EXCEPTION_SANITIZER") !=
+            UR_RESULT_SUCCESS) {
+            urLoaderConfigRelease(config);
+            error = "Failed to enable exception sanitizer layer";
+            return;
+        }
+#endif
     } else {
         error = "Failed to create loader config handle";
         return;

[kbenzie]

Not sure we need a separate option, we could always enable this as part of UR_DEVELOPER_MODE since that's enabled in CI.

[hdelan]

Thanks, have removed.

[hdelan]

So the missing part here is actually enabling the layer in the CTS environment setup, something along the lines of this:

diff --git a/test/conformance/source/environment.cpp b/test/conformance/source/environment.cpp
index 006ea09b..737d26d2 100644
--- a/test/conformance/source/environment.cpp
+++ b/test/conformance/source/environment.cpp
@@ -90,6 +90,14 @@ uur::PlatformEnvironment::PlatformEnvironment(int argc, char **argv)
             error = "Failed to enable validation layer";
             return;
         }
+#ifdef UR_ENABLE_EXCEPTION_SANITIZER
+        if (urLoaderConfigEnableLayer(config, "UR_LAYER_EXCEPTION_SANITIZER") !=
+            UR_RESULT_SUCCESS) {
+            urLoaderConfigRelease(config);
+            error = "Failed to enable exception sanitizer layer";
+            return;
+        }
+#endif
     } else {
         error = "Failed to create loader config handle";
         return;

Interesting, how was the layer working here without this call?

[pbalcer]

Interesting, how was the layer working here without this call?

The init function of all layers gets called unconditionally, and the layer themselves need to check whether they are on the enabled list.
This is so that a layer can force-enable itself if it's needed as a dependency of something else (e.g., validation layers).

[hdelan]

The init function of all layers gets called unconditionally, and the layer themselves need to check whether they are on the enabled list. This is so that a layer can force-enable itself if it's needed as a dependency of something else (e.g., validation layers).

Aha thanks @pbalcer that explains it

[hdelan]

Have updated. Should be good to go.

[igchor]

I think we should actually have a separate option to enable/disable this layer. Right now, as I understand, there is no way to disable this layer for L0 and L0 v2 adapter (other than disabling developer mode).

In L0 and L0 v2, we use exceptions to propagate errors, expecting that the loader will translate them into error codes, like here: https://github.com/oneapi-src/unified-runtime/blob/main/source/adapters/level_zero/v2/kernel.cpp#L77 .There should be no abort for L0

[kbenzie]

In L0 and L0 v2, we use exceptions to propagate errors, expecting that the loader will translate them into error codes, like here: https://github.com/oneapi-src/unified-runtime/blob/main/source/adapters/level_zero/v2/kernel.cpp#L77 .There should be no abort for L0

My personal view of this is it's a bad idea and adapters should never allow exceptions to escape the UR entry points because it is a C API. The reason this layer was created is due to exceptions crossing that ABI boundry causing crashes.

[igchor]

In L0 and L0 v2, we use exceptions to propagate errors, expecting that the loader will translate them into error codes, like here: https://github.com/oneapi-src/unified-runtime/blob/main/source/adapters/level_zero/v2/kernel.cpp#L77 .There should be no abort for L0

My personal view of this is it's a bad idea and adapters should never allow exceptions to escape the UR entry points because it is a C API. The reason this layer was created is due to exceptions crossing that ABI boundry causing crashes.

If so, I think we should then enforce each function in an adapter to be wrapped by try/catch (that is, move those auto-generated checks from loader: https://github.com/oneapi-src/unified-runtime/blob/main/source/loader/ur_libapi.cpp#L2422 to each adapter function). We could also consider making all functions (and ddi pointers) noexcept. This might allow compiler/coverity to complain if there is an uncaught exception.

[kbenzie]

If so, I think we should then enforce each function in an adapter to be wrapped by try/catch (that is, move those auto-generated checks from loader: https://github.com/oneapi-src/unified-runtime/blob/main/source/loader/ur_libapi.cpp#L2422 to each adapter function).

Since the adapters are not generated from the yaml source, that could get quite manual and annoying.

We could also consider making all functions (and ddi pointers) noexcept. This might allow compiler/coverity to complain if there is an uncaught exception.

This is an interesting approach and should be much less of a burden to add to adapters. I doubt we could do that as part of the ur_api.h header though. If we can make compilers emit diagnostics, that would be ideal.

[igchor]

If so, I think we should then enforce each function in an adapter to be wrapped by try/catch (that is, move those auto-generated checks from loader: https://github.com/oneapi-src/unified-runtime/blob/main/source/loader/ur_libapi.cpp#L2422 to each adapter function).

Since the adapters are not generated from the yaml source, that could get quite manual and annoying.

Well, we could also add this try/catch to urGet*ProcAddTable when creating a ddi tables in adapters (which are auto-generated). Something like this:

urGetEnqueueProcAddrTable(...) {
    pDdiTable->pfnEventsWait = [](auto... args) { 
      try {
          return urEnqueueEventsWait(args...);
      } catch(...) { return exceptionToResult(std::current_exception()); 
    };
  
    ...    
}

I belive the compiler will optimize it so there should be no additional overhead but we can verify that.

[kbenzie]

For the static linking use case there won't be any DDI tables, this needs to happen in the adapters not in some wrapping layer.

[igchor]

Okay, I see; then it's probably case by case. I will add the necessary try/catch blocks to the v2 adapter.

[martygrant]

Unified Runtime -> intel/llvm Repo Move Notice

Information

The source code of Unified Runtime has been moved to intel/llvm under the unified-runtime top-level directory,
all future development will now be carried out there. This was done in intel/llvm#17043.

The code will be mirrored to oneapi-src/unified-runtime and the specification will continue to be hosted at oneapi-src.github.io/unified-runtime.

The contribution guide has been updated with new instructions for contributing to Unified Runtime.

PR Migration

All open PRs including this one will be labelled auto-close and shall be automatically closed after 30 days.
To allow for some breathing space, this automation will not be enabled until next week (27/02/2025).

Should you wish to continue with your PR you will need to migrate it to intel/llvm.
We have provided a script to help automate this process.

---

This is an automated comment.

[martygrant]

Unified Runtime -> intel/llvm Repo Move Notice

Following on from the previous notice, we have now enabled workflows to automatically label and close PRs because the Unified Runtime source code has moved to intel/llvm.

This PR has now been marked with the auto-close label and will be automatically closed after 30 days.

Please review the previous notice for more information, including assistance with migrating your PR to intel/llvm.

Should there be a reason for this PR to remain open, manually remove the auto-close label.

---

This is an automated comment.

[github-actions]

Automatic PR Closure Notice

Information

This PR has been closed automatically. It was marked with the auto-close label 30 days ago as part of the Unified Runtime source code migration to the intel/llvm repository - intel/llvm#17043.

All Unified Runtime development should be done in intel/llvm, details can be found in the updated contribution guide.
This repository will continue to exist as a mirror and will host the specification documentation.

Next Steps

Should you wish to re-open this PR it must be moved to intel/llvm. We have provided a script to help automate this process, otherwise no actions are required.

---

This is an automated comment.