SDL_SetRenderTarget crash in Android

[rtrussell]

@Sylvain_Becker

indeed, that’s a corner case and not handled…

The crash is happening in SDL_render_gles.c here:

data->glBindTexture(GL_TEXTURE_2D, texturedata->texture);

where texturedata is NULL, hence the SIGSEGV. The code could easily test texturedata but it’s in a void function SetCopyState() so there’s no easy way to return ‘fail’, and anyway it’s quite deep in the call stack:

SDL_SetRenderTarget()
FlushRenderCommands()
GLES_RunCommandQueue()
SetCopyState()

Would there be any merit in simply not binding the texture when texturedata is NULL, or would that likely leave the system in an unstable state?

[Sylvain_Becker]

Texturedata should not be null, it s allocatted at creation.

it means the texture has an issue in creation

[rtrussell]

@Sylvain_Becker

it means the texture has an issue in creation

Why would rotation between portrait and landscape affect texture creation? And why is a texture being created anyway (my code doesn’t recreate the target texture unless a SDL_RENDER_TARGETS_RESET event is received, which shouldn’t happen as a result of rotation).

[rtrussell]

@rtrussell

The crash is happening in SDL_render_gles.c here:

data->glBindTexture(GL_TEXTURE_2D, texturedata->texture);

Changing that line as follows prevents the crash without any obvious negative side-effects, although it’s not tackling the root cause of the problem:

data->glBindTexture(GL_TEXTURE_2D, texturedata ? texturedata->texture : 0);

[Sylvain_Becker]

even if it works, it doesn’t seem correct …
it strange that the Texturedata is null…
I would log the texture create/destroy (SDL_render_gles.c)
maybe it needs a flush renderer…
because setcopystate seems to execute a command from an old destroyed texture

[Sylvain_Becker]

in GL renderer ( not GLES !) (but same for GLES2)

it starts with:

GL_CreateTexture(
…
renderdata->drawstate.texture = NULL; /* we trash this state. */

maybe we need the same line for GLES
see commits:

render: Fix OpenGL draw state cache for various points of texture binding.

opengles2: keep cached texturing state correct.

[rtrussell]

@Sylvain_Becker

I would log the texture create/destroy (SDL_render_gles.c)

But what texture is being created/destroyed? Evidently it’s not my render target texture, because if that was destroyed, or not created correctly, my app wouldn’t work (most likely I’d get a black screen) and that would be obvious.

I also note that in GLES_SetRenderTarget() texturedata is dereferenced, so it’s obviously not NULL at that point:

    texturedata = (GLES_TextureData *) texture->driverdata;
    data->glBindFramebufferOES(GL_FRAMEBUFFER_OES, texturedata->fbo->FBO);

So presumably the texturedata in GLES_SetRenderTarget() is not the same as the texturedata in SetCopyState(), but that’s as far as my analysis goes.

[Sylvain_Becker]

That’s a command old texture / to udate gl state.

Apply the same kind of patch as in the previous message. It sounds GLES1 hasn’t been updated the same way as GL and GLES2

[rtrussell]

@Sylvain_Becker

Apply the same kind of patch as in the previous message.

The change you are suggesting I make is in GLES_CreateTexture(). I am not creating any textures in my app around the time that the crash occurs, I am simply using the render target texture that was created when the app was started.

I can’t see how any changes to CreateTexture() could be helpful, unless textures are being created ‘behind the scenes’, which I wouldn’t have expected.

[Sylvain_Becker]

actually, something similar is applied also for gles1…

opengles1: keep cached texturing state correct.

but the patch looks differents in behavior
see the texture/texturing compared to the other patch

there may be some texture creation underneath ? maybe a reference to a very old texture deleted,
you can also trace all “cmd” the renderer use to see what get pushed …