Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IMG_ReadXPMFromArray() crashes when loading XPM from memory instead of file #4

Closed
SDLBugzilla opened this issue Feb 11, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: unspecified
Reported for operating system, platform: Linux, x86

Comments on the original bug report:

On 2006-07-19 08:30:52 +0000, Pierre Sarrazin wrote:

My code calls IMG_ReadXPMFromArray(char **xpm) to create an SDL_Surface from an XPM array in memory. That function calls load_xpm(xpm, NULL). That NULL is the 'src' argument, of type SDL_RWops. The first thing that load_xpm() does with 'src' is to call SDL_RWtell(src). SDL/SDL_rwops.h defines SDL_RWtell(ctx) as (ctx)->seek(ctx, 0, RW_SEEK_CUR). Since 'ctx' is null, the process crashes. This all happens in IMG_xpm.c.

This happens with SDL_image 1.2.5. Version 1.2.4 had a different implementation for load_xpm(): it called get_next_line(xpmlines, src, 0) instead of SDL_RWtell(src). get_next_line() did not use 'src' if 'xpmlines' was non-null.

On 2006-07-22 00:37:49 +0000, Michael Koch wrote:

Created attachment 150
Patch fixing several segfaults

I have got a patch for the same problem in Debian. Applications that worked with SDL_Image 1.2.4 segfaulted a lot with SDL_Image 1.2.5. The attached patch fixes this. I already use this patch in Debian and it looks okay.

On 2007-02-13 05:08:38 +0000, Ryan C. Gordon wrote:

This patch is now in Subversion (revision # 2970).

Thanks!

--ryan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant