Re: [png-mng-implement] Memory corruption errors when using libpng 1.5

[Mason W. <mas...@ya...>]

Thank you, but unfortunately that's not particularly helpful.  As I pointed out, 


the errors are occurring inside libpng internal routines, not at the point where 

the libpng calls return to SDL, and there don't appear to be any SDL callbacks 
involved here.

SDL_Image has two ways of loading libpng.  The default will dynamically load the 

DLL and build a struct full of function pointers with GetProcAddress and casting 

to the right signature.  It can also link against libpng.lib and build the 
struct directly from the declarations in png.h, with no casts.  I switched to 
that mode and recompiled. No compiler warnings or errors, and the same runtime 
issues happened in the same places.

Any other ideas?

>----- Original Message ----
>From: "jb...@ac..." <jb...@ac...>
>Subject: Re: [png-mng-implement] Memory corruption errors when using libpng 1.5
>
>From: Mason Wheeler [mailto:mas...@ya...]
>[VS2008]
>>Run-Time Check Failure #0 - The value of ESP was not properly saved across a 
>>function call.
>
>Your callback functions (or, I suspect, SDLs) need to use the C calling 
>convention.  This is probably because the SDL VStudio project file is set up to 

>compile everything by default with a different calling convention.  This is not 

>the default - by default a VStudio project will make everything use the C 
>calling convention.
>
>There should have been at least a warning when you compiled the errant code.  In 
>
>Visual Studio 2010 (pro) it's an error (C2440) and then the function call that 
>uses the pointer is a warning (C4024).  It may be that the version you have just 
>
>does a warning, but I find it difficult to believe that there isn't any 
>complaint, unless it's been disabled via a cast (or, of course, disabling 
4024.)
>
>>This doesn't seem to cause any trouble
>
>Well, apart from the fact that your stack pointer has just been trashed.
>
>[* * *]
>>and this time I end up with a corrupted stack that "returns" off into random 
>>memory and causes access violations.
>
>Right, when the function that called the callback returns.