We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 5127 - Software renderer broken between 2.0.12 and 2.0.13
Summary: Software renderer broken between 2.0.12 and 2.0.13
Status: RESOLVED FIXED
Alias: None
Product: SDL
Classification: Unclassified
Component: render (show other bugs)
Version: 2.0.13
Hardware: x86_64 All
: P2 blocker
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords: target-2.0.14
Depends on:
Blocks:
 
Reported: 2020-05-08 20:27 UTC by Konrad
Modified: 2020-06-23 04:26 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Konrad 2020-05-08 20:27:54 UTC 
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.
Comment 1 Konrad 2020-06-14 15:07:51 UTC 
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.
Comment 2 Konrad 2020-06-14 16:17:48 UTC 
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
Comment 3 Konrad 2020-06-21 15:05:47 UTC 
I have just pulled newest version from HG and it appears that this issue is now fixed.
Comment 4 Sam Lantinga 2020-06-23 04:26:39 UTC 
Great thanks!