I finally had a chance to test PRO 3.7 on a separate machine. Cloned the base-env, upgraded to 3.7, installed geopandas via python command prompt (conda install -c conda-forge geopandas) and tested our toolboxes:
1. tools within toolboxes that do not import geopandas run perfectly several times in a row without crashing
2. tools within toolboxes that import geopandas crash PRO on the second run
This is highly frustrating as our company would like to use several new features implemented in PRO since 3.3 and this bug forces us to stay with 3.3 and its limitations...
@KoryKramer Is there any chance this bug might be fixed with a patch in the near future as it was in BUG-000176923?
Update:
I did some further research and found the following:
Apparently on import of third party libraries in .pyt-toolboxes pointers to C-libraries are loaded in PROs application memory and are NOT deleted after tool-execution to make further runs of python processes faster. Good thinking, but this causes a memory access violation that terminates ArcGISPro.exe on OS-level.
To stop this I moved all imports from the top of the .pyt file to within the def execute() part of the tool to isolate imports and keep them out of the main toolbox (and therefore application?) scope.
Then added
def isLicensed(self):
return True
to force an external process execution thread (as suggested by Gemini).
The import of geopandas within the execute function (and therefore an isolated thread?) works, but then the tool crashes again on the second run, which again hints to a polluted memory in the main memory caused by the non-isolated python-process.
Another approach was to add the following to the top of the pyt-file, again resulting in crashing on the second run:
import geopandas as gpd
import importlib
importlib.reload(gpd)
I'm out of ideas and time to try find a solution but hope this might help to find out, why those tools still work in PRO 3.3 and crash in PRO 3.5/3.7.
