<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>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.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Jonathan<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:7.5pt;font-family:"Verdana","sans-serif";
color:#42A53D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Tamas Szekeres
[mailto:szekerest@gmail.com] <br>
<b>Sent:</b> Thursday, April 01, 2010 2:28 AM<br>
<b>To:</b> Shaw, Jonathan-P29740<br>
<b>Cc:</b> gdal-dev@lists.osgeo.org<br>
<b>Subject:</b> Re: [gdal-dev] Memory corruption in PNG driver with Microsoft
DebugDLLs?<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal>2010/4/1 Shaw, Jonathan-P29740 <<a
href="mailto:Jonathan.Shaw@gdc4s.com">Jonathan.Shaw@gdc4s.com</a>><o:p></o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>Upon further browsing of the
open tickets, I'm wondering if I'm<br>
experiencing the crashes, heap corruption, etc. described by<br>
<a href="http://trac.osgeo.org/gdal/ticket/3346" target="_blank">http://trac.osgeo.org/gdal/ticket/3346</a>.<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-bottom:12.0pt'><br>
Jonathan,<br>
<br>
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: <a
href="http://szekerest.blogspot.com/2010/02/redistribution-of-shared-c-runtime.html">http://szekerest.blogspot.com/2010/02/redistribution-of-shared-c-runtime.html</a><br>
<br>
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
<a href="http://vbkto.dyndns.org/sdk/">http://vbkto.dyndns.org/sdk/</a> which
are guaranteed to compiled satisfying with the requirements above (by using the
/MD settings for all, and the same compiler used).<br>
<br>
<br>
Best regards,<br>
<br>
Tamas<br>
<br>
<o:p></o:p></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</body>
</html>