macOS Texture::update -> glTexSubImage2D crash

[j.keller51]

Hi,

I'm experiencing a crash in Texture::update. It happens on the line:

glCheck(glTexSubImage2D(GL_TEXTURE_2D, 0, x, y, width, height, GL_RGBA, GL_UNSIGNED_BYTE, pixels));

I am on MacOS 10.15.6 using SFML 2.5.1, self-built with CMake.

The crash is due to EXC_BAD_ACCESS.

Here's where it gets weird.

The image dimensions are 1403 x 132. Since each pixel is 4 bytes, we have a total data size of 740784 bytes. When debugging, the size of Texture::m_pixels is exactly 740784 bytes.

Inside Texture::update(), const Uint8* pixels is a valid pointer to the start of Texture::m_pixels's internal buffer.

However the bad access crash is telling me it was trying to access a memory location 741376 bytes past pixels. It's over-reading by 592 bytes for some reason.

Just to confirm the input arguments once more:
x = 0
y = 0
width = 1403
height = 132

I don't know anything about OpenGL but it doesn't make sense to me that it is reading more data than width * height * 4. Could another application be interfering somehow?

Thanks

[eXpl0it3r]

Do you have the call stack for the crash?
And a minimal but compilable code example?

[j.keller51]

Call stack:
sf::Texture::update(const Uint8* pixels, unsigned int width, unsigned int height, unsigned int x, unsigned int y)
sf::Texture::update(sf::Image const&)
sf::Texture::loadFromImage(const Image& image, const IntRect& area)
sf::Texture::loadFromFile(const std::string& filename, const IntRect& area)
<< My code generating the filename string and calling sf::Texture::loadFromFile with only the 1st argument >>

As for a minimal example, I'd be happy to set one up. But I can almost guarantee that in this case, "minimal" will still require a few steps for another tester to reproduce the issue. I do know that it is reproducible on other MacOS catalina computers, though I am not sure about other macOS versions.

[j.keller51]

In other words, let me know if you have the time and are willing to follow me down the example project rabbit hole and I will oblige. It will involve some time from both of us though.

[j.keller51]

eXpl0it3r and I moved to DMs to troubleshoot this issue, in part because the code I am working with has some proprietary elements.

And important detail, and something I failed to mention in the OP, is that my SFML code is compiled in a shared library plugin that is called on and created inside of a host UI. Specifically, my plugin is a vst3 audio plugin that runs inside of digital audio workstations, and the host in this case was FL Studio.

It seems that FL Studio is using OpenGL for its UI, just like SFML. This is causing conflicts in the OpenGL state. So even though my code itself is not using OpenGL, I still need to save and restore the state as described here: https://www.sfml-dev.org/tutorials/2.5/window-opengl.php#using-opengl-together-with-the-graphics-module

When using sf::RenderWindow::pushGLStates() and sf::RenderWindow::popGLStates() around my drawing code, the crashing went away.

One final question: the documentation says that these functions can be quite expensive. Is that something I should worry about? E.g. maybe I only push/pop GL states in certain DAWs that are known to use OpenGL and cause issues.

Since I have no control or knowledge of the DAW's OpenGL usage, I can't optimize which states to save, so that seems to be off the table.

[j.keller51]

I'm finding that there are some other SFML functions that need to be wrapped by sf::RenderWindow::pushGLStates() and sf::RenderWindow::popGLStates() as well, even though on the surface they don't appear to be "drawing" functions.

For example, functions like sf::Texture::loadFrom____(), which internally end up doing some OpenGL calls (and in my case, crash FL Studio). So it's not just <object>.draw() calls that need to be protected.