Closed lgritz closed 3 months ago
This was a special run as I was trying to debug something unrelated. Ordinarily my daily sanitizer runs are for OCIO 2.1 and have never found any problems in OCIO. I haven't tried 2.2, so I don't know if this is truly new with 2.3 or has been there for a while. I'll try to run it through 2.2 as well and see what happens.
Sorry for the typos. Anyplace above where I typed OCIO 3.2, I meant 2.3, of course.
2.2 also for me:
+ /home/runner/work/oiio/oiio/dist/bin/oiiotool --version
=================================================================
==32473==ERROR: AddressSanitizer: container-overflow on address 0x611000012a70 at pc 0x7f9a6295e397 bp 0x7fff10e0c770 sp 0x7fff10e0bf18
READ of size 3 at 0x611000012a70 thread T0
#0 0x7f9a6295e396 in __interceptor_memcpy ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
#1 0x7f9a54debb22 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_append(char const*, unsigned long) (/lib/x86_64-linux-gnu/libstdc++.so.6+0x14db22)
#2 0x7f9a519e9a98 in OpenColorIO_v2_2::JoinStringEnvStyle(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.2+0x43ea98)
#3 0x7f9a5184cc17 in OpenColorIO_v2_2::(anonymous namespace)::load(YAML::Node const&, std::shared_ptr<OpenColorIO_v2_2::Config>&, char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.2+0x2a1c17)
#4 0x7f9a51851087 in OpenColorIO_v2_2::OCIOYaml::Read(std::istream&, std::shared_ptr<OpenColorIO_v2_2::Config>&, char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.2+0x2a6087)
#5 0x7f9a516f0ae0 in OpenColorIO_v2_2::Config::Impl::Read(std::istream&, char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.2+0x145ae0)
#6 0x7f9a516f0b73 in OpenColorIO_v2_2::Config::CreateFromStream(std::istream&) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.2+0x145b73)
#7 0x7f9a516f119e in OpenColorIO_v2_2::Config::CreateFromBuiltinConfig(char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.2+0x14619e)
#8 0x7f9a516fa783 in OpenColorIO_v2_2::Config::CreateFromFile(char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.2+0x14f783)
#9 0x7f9a5be20e8b in OpenImageIO_v2_5_2::ColorConfig::reset(OpenImageIO_v2_5_2::basic_string_view<char, std::char_traits<char> >) /home/runner/work/oiio/oiio/src/libOpenImageIO/color_ocio.cpp:610
#10 0x7f9a5be202a4 in OpenImageIO_v2_5_2::ColorConfig::ColorConfig(OpenImageIO_v2_5_2::basic_string_view<char, std::char_traits<char> >) /home/runner/work/oiio/oiio/src/libOpenImageIO/color_ocio.cpp:569
#11 0x55fc870c2c4b in OpenImageIO_v2_5_2::OiioTool::Oiiotool::Oiiotool() /home/runner/work/oiio/oiio/src/oiiotool/oiiotool.cpp:114
#12 0x55fc871f0abf in main /home/runner/work/oiio/oiio/src/oiiotool/oiiotool.cpp:7384
#13 0x7f9a54448d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f)
#14 0x7f9a54448e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f)
#15 0x55fc870aa4a4 in _start (/home/runner/work/oiio/oiio/dist/bin/oiiotool+0x7bd4a4)
Could be a false positive. It's just the first time I've seen this happening. I didn't realize my nightly ASAN run was still using OCIO 2.1.
If a part of the application is built with asan and another part is not instrumented, and both parts use e.g. instrumented std::vector, asan may report non-existent container overflow.
It could totally be this. I think in this case, I may in fact be building OIIO with asan but not OCIO. Might be a false positive. If you are running ASAN regularly, I'll assume there's no problem on the OCIO side.
I guess you could try to compile OCIO itself with the ASAN flag, but otherwise probably safe to ignore with ASAN suppression file / option. If you have the calling code that triggers this issue, we can always double check on our side to make sure there no issue.
Does OCIO routinely do a CI run with address sanitizer enabled?
In OpenImageIO where I've built against OCIO 2.3, everything seems to run fine for ordinary tests, but when I try it with the address sanitizer, I'm hitting the following crash with stack trace, maybe it will ring a bell or encourage you to dig into it:
This is happening early, when the config is read, long before any color transformations are attempted or any processor is built.