PNG loading & multiple heaps (WIN2000)

Great work tracking this down. I’ll look at it if I get a chance.

Basically the fix involves adding a function the SDL_image API that
frees a surface created by the IMG_Load functions.

Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Hello,

I had exactly the same problem on Win2K and WinNT, but it worked fine on
Win9x. I thought it was related to my cross-compiled dll’s. I was
planning on trying out a newer version of libpng, cause i’m currently
using 1.0.3.

If you figure it out, let me know.–
Brian

On Tue, 11 Apr 2000, Antonin Hildebrand wrote:

Hi,
I’m in troubles with this piece of code (in my little game):
SDL_Surface* LoadImage(SDL_RWops *src)
{
SDL_Surface *s;
SDL_Surface *temp;
temp = IMG_LoadPNG_RW(src);
if (!temp) return NULL;
s = SDL_DisplayFormat(temp);
SDL_FreeSurface(temp); // here dealocation fails
return s;
}

Configuration:
W2K, VC++ 6.0,
modules: SDL, SDL_main, SDL_image, SDL_mixer, pnglib, zlib - all compiled
by me in debug single-threaded mode

Problem:
I’m sure the PNG I’m trying to load is valid. (I traced code - all loaded
OK, surface conversion worked also)
There is dealocated surface’s (temp->pixels) memory in
L_FreeSurface(temp) - by calling free(temp->pixels);
and this free() function stops somewhere at hardcoded breakpoint inside heap
manager’s code (i’m running in debug mode).

I traced program deeply into the crt-code and I found that call
HeapValidate(_crtheap, 0, pHdr(temp)) fails.

this says MSDN help about HeapValidate func:
"Return Values
If the specified heap or memory block is valid, the return value is nonzero.

If the specified heap or memory block is invalid, the return value is zero.
On a system set up for debugging, the HeapValidate function then displays
debugging messages that describe the part of the heap or memory block that
is invalid, and stops at a hard-coded breakpoint so that you can examine the
system to determine the source of the invalidity."

To getting closer, I removed “security macros” from some crt DBGHEAP headers
and I included them.
By observing _crtheap handle I found out that this handle is changing for
each module.
e.g.
in main program is 0x00a00000
and when I step into the SDL_image code handling PNG loading, it changes to
0x002c0000
there is allocated surface->pixels memory (calling malloc) to this heap
and when returns from IMG_LoadPNG_RW, I call SDL_FreeSurface(temp);
in SDL_FreeSurface is _crtheap again changed and that’s why
free(temp->pixels) fails,

because it tries to dealocate memory from ANOTHER heap


loading BMPs works OK, because code to load, allocate and deallocate surface
memory is situated in the same module (i’m expecting)

I’m newbie to SDL, so thank you for any help (and sorry for my poor English)
Sam: Thank you for SDL, it’s great library

Antonin Hildebrand aka Woid
[hildi at atlas.cz]

Hi,
I’m in troubles with this piece of code (in my little game):
SDL_Surface* LoadImage(SDL_RWops *src)
{
SDL_Surface *s;
SDL_Surface *temp;
temp = IMG_LoadPNG_RW(src);
if (!temp) return NULL;
s = SDL_DisplayFormat(temp);
SDL_FreeSurface(temp); // here dealocation fails
return s;
}

Configuration:
W2K, VC++ 6.0,
modules: SDL, SDL_main, SDL_image, SDL_mixer, pnglib, zlib - all compiled
by me in debug single-threaded mode

Problem:
I’m sure the PNG I’m trying to load is valid. (I traced code - all loaded
OK, surface conversion worked also)
There is dealocated surface’s (temp->pixels) memory in
L_FreeSurface(temp) - by calling free(temp->pixels);
and this free() function stops somewhere at hardcoded breakpoint inside heap
manager’s code (i’m running in debug mode).

I traced program deeply into the crt-code and I found that call
HeapValidate(_crtheap, 0, pHdr(temp)) fails.

this says MSDN help about HeapValidate func:
"Return Values
If the specified heap or memory block is valid, the return value is nonzero.

If the specified heap or memory block is invalid, the return value is zero.
On a system set up for debugging, the HeapValidate function then displays
debugging messages that describe the part of the heap or memory block that
is invalid, and stops at a hard-coded breakpoint so that you can examine the
system to determine the source of the invalidity."

To getting closer, I removed “security macros” from some crt DBGHEAP headers
and I included them.
By observing _crtheap handle I found out that this handle is changing for
each module.
e.g.
in main program is 0x00a00000
and when I step into the SDL_image code handling PNG loading, it changes to
0x002c0000
there is allocated surface->pixels memory (calling malloc) to this heap
and when returns from IMG_LoadPNG_RW, I call SDL_FreeSurface(temp);
in SDL_FreeSurface is _crtheap again changed and that’s why
free(temp->pixels) fails,

because it tries to dealocate memory from ANOTHER heap----------------------------------------------------------------------------

loading BMPs works OK, because code to load, allocate and deallocate surface
memory is situated in the same module (i’m expecting)

I’m newbie to SDL, so thank you for any help (and sorry for my poor English)
Sam: Thank you for SDL, it’s great library

Antonin Hildebrand aka Woid
[@Antonin_Hildebrand]