[postgis-devel] Winnie is whining

[Paragon Corporation]

Nicklas,

 

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.

 

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.

 

So back to dirty memory theory and 32-bit more sensitive since it has a lot less address space to work with.

 

Thanks,

Regina

 

 

 

----------------------------------------------ORIGINAL MESSAGE ---

Hmm, I don't know. 
 
That "free(): invalid next size (fast):"
seems to be a quite generic memory error:
http://stackoverflow.com/questions/4729395/error-free-invalid-next-size-fast
 
As the answer says in the link it doesn't even have to be happening just
where it crashes. You said something about that the error moved when you
removed that test, right?
That could point in the direction that there already is some dirty
memory when getting that far.
 
I cannot replicate this so I have trouble testing and searching.
 
But what I would try is removing the last part of "test_lwgeom_tcpa"
row 1093 to 1102 in cu_measures.c
 
It is just for testing. But the M-value in that run is quite big. I
haven't read all parts of the code. But if that value is squared
somewhere it doesn't fit in a double any more. And I guess if it is
stored in a double from the heap strange things might happen.
But I don't know, just a thought. I looked into some of the code, but
couldn't see anything obvious. 
 
If I recall right someone (Paul or Sandro) removed the sqrt from some
comparing distance-calculations not so long time ago. That could maybe
also cause some very big numbers to store somewhere.
 
I remember that when I was working with the distance function rewriting
in 2009 I tested something like that. I tried to avoid sqrt internally
before the smallest distance was found. And then just do that
calculation on the result. But I ran into strange phenomenas which I
suspected had to do with storing too big numbers. But I was never sure
about what the problem was. Just realized it wasn't stable code :-)
 
I think Paul or Sandro might have more ideas about what it can be. 
 
Thanks
 
Nicklas 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20150531/4699a989/attachment.html>