<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=utf-8"><meta name=Generator content="Microsoft Word 15 (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;}
/* 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;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:"Courier New";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></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=WordSection1><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Nicklas,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Regarding the below, unfortunately after I changed that line and changed it back, I can't replicate the issue anymore on my dev computer and mine was happening after the tcpa in the next test so doesn't seem to be the test that is the cuplprit is where it fails.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>On Winnie After I moved her 32-bit test above the others, not seeing the issue.  Just forced a rerun and still fine.  But can't be positive since sometimes it failed on her and sometimes it did not, so probably have to wait for about 5 to 10 runs to be sure.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>So back to dirty memory theory and 32-bit more sensitive since it has a lot less address space to work with.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>Regina<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>----------------------------------------------ORIGINAL MESSAGE ---<o:p></o:p></span></p><pre>Hmm, I don't know. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>That "free(): invalid next size (fast):"<o:p></o:p></pre><pre>seems to be a quite generic memory error:<o:p></o:p></pre><pre><a href="http://stackoverflow.com/questions/4729395/error-free-invalid-next-size-fast">http://stackoverflow.com/questions/4729395/error-free-invalid-next-size-fast</a><o:p></o:p></pre><pre><o:p> </o:p></pre><pre>As the answer says in the link it doesn't even have to be happening just<o:p></o:p></pre><pre>where it crashes. You said something about that the error moved when you<o:p></o:p></pre><pre>removed that test, right?<o:p></o:p></pre><pre>That could point in the direction that there already is some dirty<o:p></o:p></pre><pre>memory when getting that far.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>I cannot replicate this so I have trouble testing and searching.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>But what I would try is removing the last part of "test_lwgeom_tcpa"<o:p></o:p></pre><pre>row 1093 to 1102 in cu_measures.c<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>It is just for testing. But the M-value in that run is quite big. I<o:p></o:p></pre><pre>haven't read all parts of the code. But if that value is squared<o:p></o:p></pre><pre>somewhere it doesn't fit in a double any more. And I guess if it is<o:p></o:p></pre><pre>stored in a double from the heap strange things might happen.<o:p></o:p></pre><pre>But I don't know, just a thought. I looked into some of the code, but<o:p></o:p></pre><pre>couldn't see anything obvious. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>If I recall right someone (Paul or Sandro) removed the sqrt from some<o:p></o:p></pre><pre>comparing distance-calculations not so long time ago. That could maybe<o:p></o:p></pre><pre>also cause some very big numbers to store somewhere.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>I remember that when I was working with the distance function rewriting<o:p></o:p></pre><pre>in 2009 I tested something like that. I tried to avoid sqrt internally<o:p></o:p></pre><pre>before the smallest distance was found. And then just do that<o:p></o:p></pre><pre>calculation on the result. But I ran into strange phenomenas which I<o:p></o:p></pre><pre>suspected had to do with storing too big numbers. But I was never sure<o:p></o:p></pre><pre>about what the problem was. Just realized it wasn't stable code :-)<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>I think Paul or Sandro might have more ideas about what it can be. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Thanks<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Nicklas <o:p></o:p></pre><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p></div></body></html>