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 4935 - [REGRESSION] Loading XCF files is broken on 32-bit as of 2.0.5
Summary: [REGRESSION] Loading XCF files is broken on 32-bit as of 2.0.5
Status: RESOLVED FIXED
Alias: None
Product: SDL_image
Classification: Unclassified
Component: misc (show other bugs)
Version: 2.0.5
Hardware: x86 Windows 7
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-11 02:44 UTC by Austin Hurst
Modified: 2020-10-31 17:24 UTC (History)
2 users (show)

See Also:

Attachments
patch for SDL2 (1.07 KB, patch)
2020-10-26 22:33 UTC, miniupnp@free.fr 		Details | Diff
Patch for SDL1.2 (816 bytes, patch)
2020-10-26 22:34 UTC, miniupnp@free.fr 		Details | Diff
View All 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 Austin Hurst 2020-01-11 02:44:38 UTC 
I'm one of the maintainers of the pysdl2 project, and have spent a good chunk of the past week updating the test/CI suite to support the current set of SDL2 libraries. In the process, I think I've found a regression in SDL2_image from 2.0.4 to 2.0.5: loading XCF images (well, our test XCF image) no longer works with the official 32-bit Windows runtime DLLs (returns a null pointer instead of a surface).

Here's the Appveyor output for a commit before I disabled XCF tests on 32bit: https://ci.appveyor.com/project/a-hurst/py-sdl2/builds/29985808

You can see that the tests for IMG_LoadXCF_RW (and other image-loading functions with the .xcf test image) fail with the 32-bit SDL2_image 2.0.5, but pass with the 64-bit SDL2_image 2.0.5 and with the 32-bit SDL2_image 2.0.4 & 2.0.2.

While trying to figure out if it was a pysdl2 or SDL2_image problem, I dug into the source history and found this commit between 2.0.4 and 2.0.5 that looks like a likely culprit, a commit that adds support for 64-bit offsets in XCF files: https://hg.libsdl.org/SDL_image/rev/6536f264b1eb

Not sure how common XCF loading in SDL2 actually is, but I figured you'd want the heads-up!
Comment 1 Ozkan Sezer 2020-10-26 16:22:28 UTC 
Reopened and dropped a note about this at 
https://bugzilla.libsdl.org/show_bug.cgi?id=4413
Comment 2 miniupnp@free.fr 2020-10-26 22:19:23 UTC 
OK, I think I understand what's going on.
XCF files normally have the version in their header, just like 
00000000  67 69 6d 70 20 78 63 66  20 76 30 31 31 00 00 00  |gimp xcf v011...|

but this one has 
00000000  67 69 6d 70 20 78 63 66  20 66 69 6c 65 00 00 00  |gimp xcf file...|

I think it should be interpreted as version 0
Comment 3 miniupnp@free.fr 2020-10-26 22:33:59 UTC 
Created attachment 4486 [details]
patch for SDL2
Comment 4 miniupnp@free.fr 2020-10-26 22:34:32 UTC 
Created attachment 4487 [details]
Patch for SDL1.2
Comment 5 Ozkan Sezer 2020-10-26 23:05:40 UTC 
Thanks, patches applied.

SDL-1.2 branch: https://hg.libsdl.org/SDL_image/rev/bbbffe655cc8

Default branch: https://hg.libsdl.org/SDL_image/rev/80a5e1347ee6

Tested the default branch and seen that showimage does load XCFs.
@Austin Hurst: Is it working for you?  Shall I close this?
Comment 6 Ozkan Sezer 2020-10-31 17:24:13 UTC 
Closing as fixed.