In this demo
- two cpp files are mexed to provide two separate functions: kdtree_build and kdtree_delete;
- A c++ object is allocated via kdtree_build, and returned as a pointer to matlab
- The c++ object is deleted by a call to kdtree_delete, the pointer is provided as an argument.
When I run it:
- Mexing and creation works fine - apart of a few uninteresting c++ warnings nothing is reported in verbose mex mode.
- The crashes happen upon deletion
- With printouts I was able to pin down that the crash happens as soon as any member of the dereferenced pointer is accessed (namely tree->ndim()).
My question: Could memory persistancy be an issue for this library? As far as I can tell the kdtree library allocates memory in the standard c++ way (new/ ~) without doing any matlab related magic. It is strange that for many the library works fine. I have no experience with mexing, only with c++ and cannot judge if the library has issues or if this example not working means that something is fishy with my whole OS/compilers/system. (Windows 10, Matlab 2016b, Visual studio 2013 c++ professional)
Ps. I cannot easily switch to an alternative kdtree implementation, I try to run code which uses this implementation as 3rd party code, and I really would prefer not to start rewriting this code.
Praise goes to Philip Borghesani who found the problem. As visual c++ longs have 4 Byte only, all occurences of long need to be replaced by intptr_t. This need to be done in the files: