Malloc incorrect cheksum for freed object

[b-a0]

Hi,

Thanks for making this software available freely. Unfortunately the unit test python test/test_ccblade.py fails with the error:

python(2482,0x7fff7c7dc000) malloc: *** error for object 0x7fd553746d88: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Abort trap: 6

Subsequently the unit test python test/test_gradients.py fails with:

~/Documents/Coding/Python/BEM/lib/python2.7/site-packages/CCBlade-1.1.1-py2.7-macosx-10.11-intel.egg/ccblade.py:363: RuntimeWarning: invalid value encountered in double_scalars dRe_dx = np.array([0.0, Re/chord, 0.0, Re*Vx/W**2, Re*Vy/W**2, 0.0, 0.0, 0.0, 0.0]) unexpected array size: new_size=9, got array with arr_size=-2251795519242240 ESegmentation fault: 11

What can I do to resolve these errors?

[ha-ko]

I'm not quite sure if that's the same problem I had, but I had success with reverting 21eaeabe2791316c824a93995b0fddc8f02bde03 .

That commit looks harmless but does some fancy array indexing somewhere, not quite sure what the problem is. The commit message isn't to telling either ;)

Would be interesting if it's the same problem.

[andrewning]

I don't know what the issue is. We are able to build on unix and Linux without this issue.

That commit doesn't do any fancy indexing it just sets the precision for all those variables to double precision instead of single. That's a necessary change if you want reliable gradients.

[ha-ko]

Building does work, but the tests fail.

I'm don't really know fortran, but isn't

INTEGER, PARAMETER :: reki=SELECTED_REAL_KIND(15, 307)

already double precision?

Also, in lines 1047-1049 (1072-1074) different function arguments are used if I'm not mistaken.

The following arrays (tempx) 1095-1110 are renamed.

Maybe I'm totally lost here but that looks like more than just a switch to double precision?

[andrewning]

yes the parameter reki is already double precision. The problem is that constants like 2.0 are not automatically double precision in fortran so I needed to append the with 2.0_dp to make them so. The rename from reki to dp was just to save characters. The change from selected_real_kind(15, 307) to kind(0.d0) was because that was supposedly more robust across different OS. You can try and see if changing that addresses the problem for you.

The other changes you refer to all only affect the derivatives and are created by the automatic differentiation routines. None of those would be called in the tests you are running and so wouldn't be the cause of failure.

[ha-ko]

Ok, sorry for bothering you with this.. Seems to be a problem of an older numpy and/or scipy version. I'll see if I can find which version exactly was problematic. But is is working now with the up to date numpy/scipy.

Thanks for your time!