Segfault in D3DRenderer |
Segfault in D3DRenderer |
Kai Sterker
Guest
|
Since there is no answer, I started looking further for the issue and also checked bugzilla for similar reports (none). Debugging further shows:
(gdb) up #1 0x000000006c7b1bff in D3D_RecreateTexture (renderer=0x32c1c0,    texture=0x5e36360) at src/render/direct3d/SDL_render_d3d.c:1007 1007       if (D3D_RecreateTextureRep(data->device, &texturedata->texture, texture->format, texture->w, texture->h) < 0) { (gdb) print texturedata $1 = (D3D_TextureData *) 0x0 Aha. It's the texture data itself that is NULL already. Lucky we did not crash when dereferencing that! But shouldn't this only be NULL when the texture was actually deleted via SDL_DestroyTexture? However: (gdb) print *texture $3 = {magic = 0x6c8b3a71 <texture_magic>, format = 390076419, access = 1,  w = 96, h = 24, modMode = 0, blendMode = SDL_BLENDMODE_NONE, r = 255 '▒',  g = 255 '▒', b = 255 '▒', a = 255 '▒', renderer = 0x32c1c0,  native = 0x5e36410, yuv = 0x0, pixels = 0x5e980c0, pitch = 288,  locked_rect = {x = 0, y = 0, w = 96, h = 24}, driverdata = 0x0, prev = 0x0,  next = 0x5e36410} That does not look deleted to me. But it offers a road forward, by adding    if (!texturedata) return 0; to D3D_RecreateTexture, and indeed, this resolves my problem. However, this only adresses the symptom, not the root cause. I may be wrong, but I don't think that half-created (or half-deleted) textures should ever show up in SDLs list of textures. So the main question is, how does it end up there? I have added proper error checking in my own code whereever it is calling SDL_CreateTexture, and those calls never failed. Any ideas? Kai On Wed, Jun 22, 2016 at 12:18 AM, Kai Sterker wrote:
|
|||||||||||||
|
Segfault in D3DRenderer |
Kai Sterker
Guest
|
Just tried with the SDL2-devel-2.0.4-mingw.tar.gz package from libsdl.org; same issue:
Thread 1 received signal SIGSEGV, Segmentation fault. 0x000000006c79976b in SDL_LogCritical () Â Â from C:\msys64\mingw64\usr\local\bin\SDL2.dll (gdb) bt #0 Â 0x000000006c79976b in SDL_LogCritical () Â Â from C:\msys64\mingw64\usr\local\bin\SDL2.dll #1 Â 0x000000006c799c6e in SDL_LogCritical () Â Â from C:\msys64\mingw64\usr\local\bin\SDL2.dll #2 Â 0x000000006c79a267 in SDL_LogCritical () Â Â from C:\msys64\mingw64\usr\local\bin\SDL2.dll #3 Â 0x000000000049c135 in screen::clear () at screen.h:140 Filed a bug report: https://bugzilla.libsdl.org/show_bug.cgi?id=3370 For now I'll keep my own SDL version with the workaround in place, but an official fix or pointer to what I am doing wrong would be hghly appreciated :-). Kai On Wed, Jun 22, 2016 at 2:42 PM, Kai Sterker wrote:
|
|||||||||||||||
|