Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: Crash when resizing Window since hg 333216331863 #1995

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Windows: Crash when resizing Window since hg 333216331863 #1995

SDLBugzilla opened this issue Feb 11, 2021 · 0 comments


Copy link

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: HG 2.1
Reported for operating system, platform: Windows 8, x86

Comments on the original bug report:

On 2015-10-11 12:12:13 +0000, Gab wrote:

SDL_renderer_d3d.c line 844

if (!texture->texture) {
return 0;

texture is NULL and crashes.

How to reproduce: Create a Window with SDL_WINDOW_RESIZABLE and resize it.

The first bad revision is 333216331863

"Use D3D9Ex when available
This hopefully works around crashes in Intel D3D9 support in Windows 8.1."

Playerd.exe!D3D_RecreateTextureRep(IDirect3DDevice9 * device, D3D_TextureRep * texture, unsigned int format, int w, int h) Zeile 844 C
Playerd.exe!D3D_RecreateTexture(SDL_Renderer * renderer, SDL_Texture * texture) Zeile 969 C
Playerd.exe!D3D_Reset(SDL_Renderer * renderer) Zeile 419 C
Playerd.exe!D3D_ActivateRenderer(SDL_Renderer * renderer) Zeile 474 C
Playerd.exe!D3D_RenderClear(SDL_Renderer * renderer) Zeile 1232 C
Playerd.exe!SDL_RenderClear(SDL_Renderer * renderer) Zeile 1354 C
Playerd.exe!SdlUi::UpdateDisplay() Zeile 543 C++

On 2015-10-11 12:14:38 +0000, Gab wrote:

Oh and this crashes with both Intel and Nvidia for me. Both have up-to-date drivers.

On 2015-12-29 16:36:38 +0000, David Ludwig wrote:

Hi Gab,

I'm unable to reproduce this on any of my Windows systems, and I'm not sure why. I created a window with SDL_WINDOW_RESIZABLE set, but was able to resize it without crashing, both with and without textures on it.

Do you have any additional details on the system(s) you used to test this on?

Any chance you could provide a sample program?

On 2015-12-29 19:32:59 +0000, Gab wrote:

Thanks for the update, I will recheck. Maybe got fixed in the meanwhile.

On 2015-12-30 19:22:12 +0000, David Ludwig wrote:

I'm also unable to reproduce this using the revision you mentioned,

Gab, might you have code for a small, sample program, which I could use to try reproducing this?

On 2016-01-12 19:59:21 +0000, Gab wrote:

Sorry, was my fault. I'm using the DirectX February 2010 SDK for compiling (since years) and just read on MSDN that they ship the DX SDK now with the Windows SDK... So removing that include fixed the crash.

On 2016-01-12 20:02:22 +0000, David Ludwig wrote:

Got it. Thanks for the updated info!

On 2016-01-13 22:06:06 +0000, Gab wrote:

I'm sorry, have to reopen. I encountered the crash again and figured out the real cause now by stepping through SDL code.

The SDL_Texture must be created with a SDL_TEXTURE_FORMAT that is not supported (returns false for "IsSupportedFormat", for me this is SDL_PIXELFORMAT_ABGR8888)

This results in two textures being created (one in unsupported format, one in supported format) and only the supported one gets the "driverdata" field assigned (makes sense because only the supported one can be used by DirectX).

But D3D_Reset just loops over all textures and passes them to D3D_RecreateTexture which accesses driverdata but does not check for NULL.

The DirectX 11 backend has a NULL check in D3D11_DestroyTexture:

D3D11_TextureData *data = (D3D11_TextureData *)texture->driverdata;

if (!data) {

On 2016-01-13 22:44:09 +0000, Gab wrote:

Created attachment 2364
Should fix the issue

Proposed patch.

The alternative codepath through D3D_DestroyTexture already checks for NULL btw ;)

On 2016-04-07 00:47:12 +0000, Stephen E. Baker wrote:

Confirmed that the patch fixed this crash for us. In our case the issue occurred when we were targeting larger than screen resolutions.

On 2016-06-22 19:09:23 +0000, Kai Sterker wrote:

*** Bug 3370 has been marked as a duplicate of this bug. ***

On 2016-06-25 02:20:23 +0000, David Ludwig wrote:

Fix applied via

Thanks for the fix, Gab!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

1 participant