MSAN Host fails with a simple SYCL code

[jkwack]

Point of Contact

JaeHyuk Kwack, Renzo Bustamante

Contact Details

No response

Vendor/ALCF/other tickets/IDs

CMPLRLLVM-75894, CMPLRLLVM-75881

Reproducer Path

/lus/flare/projects/Tools/jkwack-tools-reproducer/JaeHyuk/SAN_host_syclQ
source/reproducers/tools/msan_sycl_host

Status

Open

Details

Renzo reported MSAN issue on host, and the following simple reproducer is used to reproduce the issue:

#include <sycl/sycl.hpp>
#include <iostream>

int main() {
  sycl::queue Q;

  std::cout << "Hello, World!" << std::endl;
  return 0;
}

W/o Sanitizer, it works as expected:

jkwack@x4600c0s7b0n0:/lus/flare/projects/Tools/jkwack-tools-reproducer/JaeHyuk/SAN_host_syclQ> icpx -fsycl -g -O2 test_helloSYCL.cpp -o test_helloSYCL 

jkwack@x4600c0s7b0n0:/lus/flare/projects/Tools/jkwack-tools-reproducer/JaeHyuk/SAN_host_syclQ> ONEAPI_DEVICE_SELECTOR=level_zero:gpu ./test_helloSYCL
Hello, World!

W/ MSAN on host, it fails as follows:

jkwack@x4600c0s7b0n0:/lus/flare/projects/Tools/jkwack-tools-reproducer/JaeHyuk/SAN_host_syclQ> icpx -fsycl -g -O2 -Xarch_host -fsanitize=memory test_helloSYCL.cpp -o test_helloSYCL_msan_host 

jkwack@x4600c0s7b0n0:/lus/flare/projects/Tools/jkwack-tools-reproducer/JaeHyuk/SAN_host_syclQ> ONEAPI_DEVICE_SELECTOR=level_zero:gpu ./test_helloSYCL_msan_host
Uninitialized bytes in fopen64 at offset 19 inside [0x706000000000, 57)
==119386==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f8e080a1bb3 in std::__basic_file<char>::open(char const*, std::_Ios_Openmode, int) /tmp/root/spack-stage/spack-stage-gcc-13.4.0-hgnyg4phrjk5d774h73nfu4jmacyfoac/spack-src/spack-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98/basic_file.cc:255:25
    #1 0x7f8e080e741d in std::basic_filebuf<char, std::char_traits<char>>::open(char const*, std::_Ios_Openmode) /tmp/root/spack-stage/spack-stage-gcc-13.4.0-hgnyg4phrjk5d774h73nfu4jmacyfoac/spack-src/spack-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/fstream.tcc:184:16
    #2 0x7f8e07bebb97 in sycl::_V1::detail::readConfig(bool) config.cpp
    #3 0x7f8e07d230e0 in sycl::_V1::detail::ur::initializeUr(ur_loader_config_handle_t_*) ur.cpp
    #4 0x7f8e07c6a509 in sycl::_V1::detail::platform_impl::get_platforms() platform_impl.cpp
    #5 0x7f8e07d89d5c in sycl::_V1::platform::get_platforms() (/opt/aurora/26.26.0/oneapi/compiler/latest/lib/libsycl.so.8+0x38cd5c)
    #6 0x7f8e07d3197f in sycl::_V1::device::get_devices(sycl::_V1::info::device_type) (/opt/aurora/26.26.0/oneapi/compiler/latest/lib/libsycl.so.8+0x33497f)
    #7 0x7f8e07d34e2d in sycl::_V1::detail::select_device(std::function<int (sycl::_V1::device const&)> const&) (/opt/aurora/26.26.0/oneapi/compiler/latest/lib/libsycl.so.8+0x337e2d)
    #8 0x0000004d6729 in sycl::_V1::queue::queue<int (sycl::_V1::device const&), void>(int  const(&)(sycl::_V1::device const&), std::function<void (sycl::_V1::exception_list)> const&, sycl::_V1::property_list const&) /opt/aurora/26.26.0/oneapi/compiler/2025.3/bin/compiler/../../include/sycl/queue.hpp:213:15
    #9 0x0000004d6729 in sycl::_V1::queue::queue(sycl::_V1::property_list const&) /opt/aurora/26.26.0/oneapi/compiler/2025.3/bin/compiler/../../include/sycl/queue.hpp:191:9
    #10 0x0000004d6729 in main /lus/flare/projects/Tools/jkwack-tools-reproducer/JaeHyuk/SAN_host_syclQ/test_helloSYCL.cpp:5:15
    #11 0x7f8e0783d24c in __libc_start_main (/lib64/libc.so.6+0x3524c) (BuildId: 171a59c1c43a8f7b93c3dff765aae0b675fe10f6)
    #12 0x0000004376e9 in _start /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:120

SUMMARY: MemorySanitizer: use-of-uninitialized-value /tmp/root/spack-stage/spack-stage-gcc-13.4.0-hgnyg4phrjk5d774h73nfu4jmacyfoac/spack-src/spack-build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++98/basic_file.cc:255:25 in std::__basic_file<char>::open(char const*, std::_Ios_Openmode, int)
Exiting

Is this a priority/blocking bug?

• Priority

ETA

No response

[jkwack]

The same issue with oneapi/public/2026.0.0

[zhaomaosu]

The msan reported error should be a false alarm. This is a well-known biggest usability barrier for memory sanitizer. Unlike ASAN/TSAN, MSAN tracks data flow instead of events. It requires the entire toolchains to be instrumented to avoid false alarms.
Under the current situation, it is difficult for us to provide a msan instrumented oneapi toolkit. I remembered we have discussed this issue before?

A workaround is running msan instrumented program with runtime flag halt_on_error=0 like:

$ MSAN_OPTIONS=halt_on_error=0 ./test_helloSYCL_msan_host

Then the program execution will not be aborted by any false alarms.
If you're more focused on device code, please only enable device msan. It's hard to get any false alarm.

[colleeneb]

Thanks for the workaround! @jkwack would it be ok to close this if we update the user docs to reflect the workaround?

[jkwack]

I think so. I just pinged Renzo to check if it works fine for him or not. Thanks for the update.

[colleeneb]

@jkwack were you able to check with Renzo?