[2.8.x] Double-free if IMG_SaveJPG_RW_jpeglib() fails and IMG_SaveJPG_RW_tinyjpeg() is tried

[smcv]

To reproduce:

• Compile SDL_image with dynamic runtime loading (dlopen) and libjpeg enabled
• Somehow get SDL_image into a state where IMG_SaveJPG_RW_jpeglib() fails. I'm currently trying to backport SDL_image 2.8.2 to Steam Runtime version 1 'scout', an Ubuntu-12.04-based environment, and for whatever reason it's failing; I'll address that eventually when I've figured out what is happening, but for now, it provides a convenient way to exercise failure code-paths that are not normally reached.
• Make IMG_SaveJPG_RW_jpeglib() fail cleanly (at the moment there is another bug in its use of setjmp/longjmp: #429)
• Call IMG_SaveJPG_RW(surface, dst, 1, quality), for example via IMG_SaveJPG which is called by SDL_image's own test suite

Expected result: Saving with libjpeg fails. SDL_image tries to fall back to tinyjpeg. No crash.

Actual result: First SDL_image calls IMG_SaveJPG_RW_jpeglib(., ., freedst=1, .), and then it calls IMG_SaveJPG_RW_tinyjpeg(., ., freedst=1, .). The first call closes (frees) the destination RWops object (file). The second call is a use-after-free and then a double-free, which in my case is detected by glibc, causing an abort().

Suggested solution: Probably the entire implementation of freedst should be in IMG_SaveJPG_RW(), and the two backend-specific implementations IMG_SaveJPG_RW_jpeglib() and IMG_SaveJPG_RW_tinyjpeg() should never free the RWops object.

[slouken]

That sounds like the right solution.

[smcv]

I'll provide a PR when I've figured out what is even going on in my scout build...

[smcv]

It looks as though d2c7e0905 might have accidentally fixed this as well (it was intentionally fixing a missing close/free, but seems to have unintentionally fixed this double-free at the same time).

[smcv]

I think #430 resolves this, but I want to get to the bottom of what is happening in my scout build to have better confidence about that solution before undrafting it.