syoyo/tinyexr

UBSan issue when loading an .exr

jdumas opened this issue · 2 comments

jdumas commented

Describe the issue
Loading a certain .exr image with UBSan enabled flags some issues in tinyexr.

To Reproduce
Steps to reproduce the behavior:

  1. Compile TinyEXR with UBSan (-fsanitize=undefined)
  2. Load EXR Image with LoadEXRImageFromFile
  3. See error
tinyexr/tinyexr.h:1999:12: runtime error: left shift of 585757245565577410 by 8 places cannot be represented in type 'long long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior tinyexr/tinyexr.h:1999:12 in
tinyexr/tinyexr.h:2659:5: runtime error: left shift of 769045763242690055 by 8 places cannot be represented in type 'long long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior tinyexr/tinyexr.h:2659:5 in
tinyexr/tinyexr.h:2735:33: runtime error: left shift of 115287495861464541 by 8 places cannot be represented in type 'long long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior tinyexr/tinyexr.h:2735:33 in

Image: plastic_stripes_Height.exr.zip

Expected behavior
I am not sure whether it's an issue with our .exr image, or a problem in tinyexr, but I'd expect tinyexr to not trigger any runtime UBSan error (this one seems like a shift integer overflow?).

Environment

  • OS: macOS
  • Compiler: AppleClang 14.0.0.14000029
  • Tinyexr version: latest (02310c7)
syoyo commented

These UBSan reported line of codes points to codes ported from OpenEXR(not written by me) and somewhat difficult to understand such codes. The reason would be integer overflows. But I'm not sure simple overflow fix is sufficient. It may introduce some side-effects.

Proper solution would be replace OpenEXR-derived codes with our own #186

For a while, we can simply ignore/suppress UBSan warning: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#disabling-instrumentation-with-attribute-no-sanitize-undefined

jdumas commented

Ah the wuffs thing sounds nice. Guess I'll just ignore these issues for now, thanks!

  • ❤️1