Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deallocation Issue in Ftypes #31

Closed
rosenbrockc opened this issue Feb 27, 2015 · 2 comments
Closed

Deallocation Issue in Ftypes #31

rosenbrockc opened this issue Feb 27, 2015 · 2 comments

Comments

@rosenbrockc
Copy link
Owner

If the same shared library is repeatedly used with allocatable outputs, it appears as if it is sharing the memory between the results, so that subsequent results overwrite the first ones. It also means that the deallocation segfaults because the first pointer being released deallocates fine, but when the remaining ones try to deallocate it, it has already been deallocated.

I think it is still good to have every FtypeResult instance try to deallocate itself (it is cheap); we should just add a check for allocation before trying to deallocate. We probably also ought to investigate whether it is better to copy the array results before the method is called again. If we do the copy, there is obvious overhead and the memory becomes managed by python. If we don't copy, the user's results will be confusing with values being overwritten. If they are aware of that, they could do the copy themselves. If they are not, we have to do it transparently...

@rosenbrockc
Copy link
Owner Author

Instead, stop caching the shared library DLL instances created by python in static_symbol. If we get a new library instance each time, it should have its own memory and then the current paradigm would work correctly. In that case, the overhead would move to the shared library loading. I don't see another way around this that doesn't involve double allocation of arrays in memory and copying values over.

@rosenbrockc
Copy link
Owner Author

For now, I decided to implement a full array copy to bypass this problem. It turns out that the ctypes library loading returns the same handle to each subroutine; loading the library again does not allow a separate block of memory to be allocated for the subroutines. This seems to be an inherent problem with the ctypes implementation and the fundamental differences between C and Fortran.

Andrew will look into creating a C++ wrapper to act as intermediary between F and C via ctypes. For now, revision 1.5.1 has the updates for safe memory access and deallocation by copying arrays lazily when a subroutine is requested an additional time. I will update this once he has looked into that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant