[gdal-dev] Memory corruption in PNG driver with Microsoft DebugDLLs?

[Shaw, Jonathan-P29740]

Thanks, Tamas. Your blog posting is helpful in explaining the potential
problems and the care that must be taken. I already paid careful
attention to the memory allocation/deallocation DLL boundary concerns,
but somehow I was clueless on the issues related to compiling against
mixtures of Microsoft's debug and non-debug runtime DLLs. The recent
ticket 3346 woke me up to this issue, and your post helps explain it
further.

 

Thanks,

Jonathan

 

 

 

From: Tamas Szekeres [mailto:szekerest at gmail.com] 
Sent: Thursday, April 01, 2010 2:28 AM
To: Shaw, Jonathan-P29740
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Memory corruption in PNG driver with Microsoft
DebugDLLs?

 

 

 

2010/4/1 Shaw, Jonathan-P29740 <Jonathan.Shaw at gdc4s.com>

Upon further browsing of the open tickets, I'm wondering if I'm
experiencing the crashes, heap corruption, etc. described by
http://trac.osgeo.org/gdal/ticket/3346.


Jonathan,

You probably use GDAL along with one or more dependencies loaded
dynamically (like proj, libpng, libjpeg etc.) which may have been
compiled against different CRT dependencies. This may happen either by
using different CRT settings or different compiler versions when
compiling the various libraries. Having different CRT settings for the
various libraries is not necessarily a problems when the authors of the
libraries follow careful design considerations and coding practice (like
making memory allocations/deallocations within the dll boundaries etc.),
but it's rarely the case with the libraries we use. Using inhomogeneous
CRT dependecies in dependent libraries is unsupported by Microsoft
either, and I've also submitted a blogpost related to this topic here:
http://szekerest.blogspot.com/2010/02/redistribution-of-shared-c-runtime
.html

To avoid this situation you might want to recompile all the dependencies
with the same compiler and CRT setting which could be a nightmare in
many cases. You could alternatively use the pre-compiled binary packages
/ SDKs from this location http://vbkto.dyndns.org/sdk/ which are
guaranteed to compiled satisfying with the requirements above (by using
the /MD settings for all, and the same compiler used).


Best regards,

Tamas



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100401/403aac5e/attachment.html