| Summary: | Software renderer broken between 2.0.12 and 2.0.13 | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Konrad <iryont> |
| Component: | render | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | blocker | ||
| Priority: | P2 | Keywords: | target-2.0.14 |
| Version: | 2.0.13 | ||
| Hardware: | x86_64 | ||
| OS: | All | ||
I was recently working with my application on OS X and I've pulled 2.0.13 from HG. The issue with software renderer is there, too. In fact, since I'm using a custom 2D rasterizer I've noticed that everything related to getting window surface at least on OS X is crashing (by using returned value from SDL_GetWindowSurface which is not null, but accessing it does lead to bad access signal). I had to back out to 2.0.12 due to this. Following trace log is from lldb of OS X. Please note this only happens with SDL 2.0.13 and not SDL 2.0.12. There is an issue with SDL_GetWindowSurface, too which I believe is of the same origin.
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3a3a00000000)
frame #0: 0x000000010056c78e app`SDL_InvalidateMap(map=0x00003a3a00000000) at SDL_pixels.c:1032:14 [opt]
1029 if (!map) {
1030 return;
1031 }
-> 1032 if (map->dst) {
1033 /* Release our reference to the surface - see the note below */
1034 if (--map->dst->refcount <= 0) {
1035 SDL_FreeSurface(map->dst);
Target 0: (app) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x3a3a00000000)
* frame #0: 0x000000010056c78e app`SDL_InvalidateMap(map=0x00003a3a00000000) at SDL_pixels.c:1032:14 [opt]
frame #1: 0x000000010056f0cc app`SDL_FreeSurface_REAL(surface=0x00000000002885c0) at SDL_surface.c:1321:5 [opt]
frame #2: 0x0000000100575fc0 app`SDL_GetWindowSurface_REAL(window=0x0000000000440950) at SDL_video.c:2376:13 [opt]
frame #3: 0x00000001005262bc app`SW_RunCommandQueue at SDL_render_sw.c:63:32 [opt]
frame #4: 0x00000001005262b0 app`SW_RunCommandQueue(renderer=<unavailable>, cmd=0x00000000002acea0, vertices=0x0000000001944a00, vertsize=<unavailable>) at SDL_render_sw.c:614 [opt]
frame #5: 0x00000001004fe89b app`SDL_RenderPresent_REAL [inlined] FlushRenderCommands(renderer=<unavailable>) at SDL_render.c:222:14 [opt]
frame #6: 0x00000001004fe87b app`SDL_RenderPresent_REAL(renderer=<unavailable>) at SDL_render.c:3154 [opt]
frame #7: 0x000000010014a685 app`Application::run() + 533
frame #8: 0x00000001002bdfcd app`main + 1405
frame #9: 0x00007fff6fe23cc9 libdyld.dylib`start + 1
frame #10: 0x00007fff6fe23cc9 libdyld.dylib`start + 1
I have just pulled newest version from HG and it appears that this issue is now fixed. Great thanks! |
This issue is likely generic due to dlmalloc crash, but since it manifests itself in a software renderer here I will just include the log my application generated: exception: Access violation (0xc0000005) exception address: 0x6af91ace backtrace: 0: app.exe(dlmalloc+0x17e) [0x000000006AF91ACE] 1: app.exe(dlcalloc+0x47) [0x000000006AF92427] 2: app.exe(SDL_calloc_REAL+0x1d) [0x000000006AF924CD] 3: app.exe(SDL_AllocateRenderVertices+0x1e5) [0x000000006AF8EDB5] 4: app.exe(SDL_AllocateRenderVertices+0x79f) [0x000000006AF8F36F] 5: app.exe(SDL_AllocateRenderVertices+0x841) [0x000000006AF8F411] 6: app.exe(SDL_RenderCopyF_REAL+0x183) [0x000000006AF8E263] 7: app.exe(SDL_RenderCopy_REAL+0x53) [0x000000006AF8D523] It's newest SDL2 from HG. I did download release 2.0.12 and compiled it - works just fine, so something broke in between.