You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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...
The text was updated successfully, but these errors were encountered:
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.
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.
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...The text was updated successfully, but these errors were encountered: