search

AcademySoftwareFoundation / OpenColorIO

A color management framework for visual effects and animation.
https://opencolorio.org
BSD 3-Clause "New" or "Revised" License
1.76k stars 434 forks source link

Address sanitizer errors in OCIO 2.3 #1844

Closed lgritz closed 3 months ago

lgritz commented 12 months ago

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:

+ /home/runner/work/oiio/oiio/dist/bin/oiiotool --version
=================================================================
==32360==ERROR: AddressSanitizer: container-overflow on address 0x611000014230 at pc 0x7faeda3c7397 bp 0x7ffd070d8b70 sp 0x7ffd070d8318
READ of size 3 at 0x611000014230 thread T0
    #0 0x7faeda3c7396 in __interceptor_memcpy ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
    #1 0x7faecc854b22 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 0x7faec9448db8 in OpenColorIO_v2_3::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.3+0x456db8)
    #3 0x7faec929e0a7 in OpenColorIO_v2_3::(anonymous namespace)::load(YAML::Node const&, std::shared_ptr<OpenColorIO_v2_3::Config>&, char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.3+0x2ac0a7)
    #4 0x7faec92a2517 in OpenColorIO_v2_3::OCIOYaml::Read(std::istream&, std::shared_ptr<OpenColorIO_v2_3::Config>&, char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.3+0x2b0517)
    #5 0x7faec914feb0 in OpenColorIO_v2_3::Config::Impl::Read(std::istream&, char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.3+0x15deb0)
    #6 0x7faec914ff43 in OpenColorIO_v2_3::Config::CreateFromStream(std::istream&) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.3+0x15df43)
    #7 0x7faec915c2dc in OpenColorIO_v2_3::Config::CreateFromBuiltinConfig(char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.3+0x16a2dc)
    #8 0x7faec915c81e in OpenColorIO_v2_3::Config::CreateFromFile(char const*) (/home/runner/ext/dist/lib/libOpenColorIO.so.2.3+0x16a81e)
    #9 0x7faed3889e8b 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 0x7faed38892a4 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 0x559485d54c4b in OpenImageIO_v2_5_2::OiioTool::Oiiotool::Oiiotool() /home/runner/work/oiio/oiio/src/oiiotool/oiiotool.cpp:114
    #12 0x559485e82abf in main /home/runner/work/oiio/oiio/src/oiiotool/oiiotool.cpp:7384
    #13 0x7faecbeb1d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f)
    #14 0x7faecbeb1e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f)
    #15 0x559485d3c4a4 in _start (/home/runner/work/oiio/oiio/dist/bin/oiiotool+0x7bd4a4)

This is happening early, when the config is read, long before any color transformations are attempted or any processor is built.

lgritz commented 12 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.

lgritz commented 12 months ago

Sorry for the typos. Anyplace above where I typed OCIO 3.2, I meant 2.3, of course.

remia commented 12 months ago

We run nightly ASAN on Linux and macOS (its a relatively recent add), for example the latest are here for Linux. There are mentions of false positives for that test that could match here but I'm wondering why this would only show in 2.3 and not 2.1 builds then.

lgritz commented 12 months ago

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.

lgritz commented 12 months ago

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.

remia commented 12 months ago

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.