[BUG] Writing a very large deep EXR scanlines crashes

[dleex]

Describe the bug

Writing a large deep scanline EXR crashes.

OpenImageIO version and dependencies

OIIO 2.5.17.0 | Linux/x86_64
Build compiler: gcc 11.4 | C++17/201703
HW features enabled at build: sse2
Dependencies: , Boost 1.74.0, BZip2 NONE, DCMTK NONE, FFmpeg NONE, Freetype 2.11.1, GIF NONE, JPEG 80, Libheif
NONE, libjpeg-turbo NONE, LibRaw NONE, OpenColorIO NONE, OpenCV NONE, OpenEXR 3.3.2, OpenGL, OpenJPEG NONE, PNG
1.6.37, Ptex NONE, Ptex NONE, pybind11 2.9.1, Python 3.10.12, Qt5 NONE, Qt6 NONE, Robinmap, TBB NONE, TIFF 4.3.0,
WebP NONE, ZLIB 1.2.11

It was also reproducible in older version: OIIO 2.3.14 using OpenEXR 3.2 and also 2.2.18.

To Reproduce

Steps to reproduce the behavior:

1. Extract the attached python script
2. Run (eg 'python3 dcmbug.py')
3. Wait until it crashes

dcmbug.zip

The exact same crash can be observed when doing the same via C++ API also. If you reduce the image resolution significantly (or reduce the number of channels significantly) then it no longer crashes.
I'm reasonably certain it's OIIO-related issue and not OpenEXR because the similar test in OpenEXR does not crash.

[lgritz]

I can reproduce the crash using OIIO 3.0. I'll try to take a look over the weekend.

Incidentally, oiio.TypeDesc.TypeHalf and those types have been deprecated for many years and were finally removed in 3.0, so your python script will start giving you errors starting with 3.0. The easy fix is to use oiio.TypeHalf (those things moved to the overall namespace, not within TypeDesc), but also you may find it even simpler just to use strings, like this:

test_chantypes += ('half', 'half', 'half')

or

spec = oiio.ImageSpec (test_xres, test_yres, test_nchannels, 'float')

anyplace in the OIIO python bindings that a TypeDesc is expected, a string is just fine, too, and it will construct a TypeDesc from it.

[lgritz]

I don't suppose you could also post the C++ code that crashes?

[lgritz]

Wait, never mind, I think I recreated the equivalent myself.

[lgritz]

Found it, it's an integer overflow issue.

Testing a fix.

[dleex]

We tested the fix on our end as well and so far so good!
Thank you for the very prompt response.