Select to view content in your preferred language

Custom Python Toolbox Crashes Pro on 2nd Run after upgrading to 3.5

2629
18
09-03-2025 08:40 AM
KonradBostrom
Occasional Contributor

I've recently upgraded Pro from 3.0.3 to 3.5.2, and several of my Custom Python Toolboxes will now crash Pro if I run them a second time in a row. The tool works as expected, if I close and reopen Pro before running it again, but this isn't an issue I had on 3.0.3.

My code and input data are unchanged.

I'm curious if anyone else has experienced this behavior or has any insight into what might be causing this.

Thanks!

Tags (3)
0 Kudos
18 Replies
KonradBostrom
Occasional Contributor

Rewriting my toolbox and removing all opensource / non-default modules stopped it from crashing on rerun.

0 Kudos
Chris_Ste
Occasional Contributor

Glad this solved the issue.
Unfortunately rewriting all toolboxes within our company is no viable option.
On further research I found another BUG that also mentions geopandas: BUG-000151279 for ArcGIS Pro
Maybe @Robert_LeClair can forward that information, so the issue might be fixed in 3.7 or any following patches/hotfixes.

0 Kudos
Robert_LeClair
Esri Esteemed Contributor

@KoryKramer - does the ArcGIS Pro Dev Team know about this item/issue?

0 Kudos
Chris_Ste
Occasional Contributor

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.

Update 2:

The env for 3.3 has geopandas 1.0.1 installed, the env for 3.5 my colleague currently has 0.14.4 installed. Could it be, that dependencies in newer ArcPRO Versions require geopandas to downgrade to the last 0.X Version of geopandas (and some of its dependencies) and that this causes the crash on the second run?
Our env for 3.2 used 0.12.2 and ran perfectly, so it might be the combination of "new ArcPRO (3.4 or higher)" + "old geopandas (0.X)"

RémiBRAUN
Occasional Contributor

Hello,

Same issue here, hoping it gets fixed in 3.7 or 3.8 🙏

0 Kudos
RémiBRAUN
Occasional Contributor

**NOT WORKING**

After some investigation, more than geopandas, it seems that it's pyogrio that crashes, especially when looking for layers in the gpd.read_file function.

So you have 3 options: 

  • wait for the bug to be fixed on ESRI's border
  • set geopandas.options.io_engine = "fiona" and hope for the best
  • downgrade geopandas < 1, as it uses fiona by default, if your code allows it

Note that the geopandas registered in ESRI's conda channel doesn't install pyogrio even though it has a version > 1. So I think they are aware of the bug, although I fear they chose not to solve it...

Chris_Ste
Occasional Contributor

Thank you for sharing your solution. I'll try the fiona-approach once I'm back in the office

0 Kudos
RémiBRAUN
Occasional Contributor

Sadly I thought it was it... After further testing including on other computers, I have the crash behaviour back (only with tools importing geopandas).

It's true even if the installed geopandas comes from esri's forge and pyogrio is not installed or with geopandas < 1...

0 Kudos
RémiBRAUN
Occasional Contributor

I tried another env without any lib coming from conda-forge channel.

  • ESRI channel alone cannot solve an environment, the defaults is needed: 
    image.png
  • The resulting env mixing esri and main channels is still crashing, nothing to do with conda-forge 🙃
0 Kudos