nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

KonradBostrom

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!

Finde mehr Beiträge mit dem Tag

Desktop

Accepted answers

All comments

Robert_LeClair

I wonder if the Python environment may need to be repaired? You can learn more about this workflow here - Repair an environment—ArcGIS Pro | Documentation

KonradBostrom

Hi Robert,

Thanks for the suggestion! My environment manager doesn't show the 'Warning icon' for the environment, and I didn't have the option to repair it. I did try to run the toolbox twice with a new clone of the default python environment and had the same issue.

Any other suggestions?

Robert_LeClair

Well at least we know it's not a bad environment. Another thing to try is to create a new Python in a new Project. Add the old Python toolbox to the new project and copy and paste the original tool to the new toolbox. Run the tool again. Does ArcGIS Pro still crash?

Chris_Ste

Hi,

I'm having the same Problem: First run works, the second crashes PRO. After I reopen the project it works again for one time then crashes again.

Tried with different projects and Data, always crashes on the second run.
Tested the code again with PRO Version 3.3 and it runs several times without crashing.

There's a bug-report (BUG-000176923) on that issue, with what I can only assume is a joke as a workaround ("Use ArcGIS Pro 3.3, where the tool completes successfully.").
It specifies Windows 10 as OS, but PRO also crashes on my Windows 11 machine.

KonradBostrom

Hi Chris,

Have you found a solution for this? I haven't had any luck personally.

Best, Konrad

Robert_LeClair

In reviewing the BUG-000176923 report, it does say it's currently under review. Hopefully it is fixed at ArcGIS Pro 3.7!

DFarming

I have a script that reads a shapefile into a geodataframe, it always crashes the second time it is ran as of upgrading to 3.6 (from 3.5).

If I run the script it works the first time, if I run it again it crashes.
If I run the script it works, if I then make any changes to the script code and save, I can run it a second time with no crash. Is it not properly clearing the kernel or something?

Chris_Ste

There has been an update on BUG-000176923. It seems to not be reproducible.
I did some testing and it might have something to do with modules imported within the toolbox. We use an environment that has several modules more than the base-env. When we use toolboxes with that environment that only uses modules found in the base-env, it seems to work. As soon as we use toolboxes that use e.g. geopandas and/or psycopg2 the tool crashes on the second run.
@DFarming seems like geopandas could be the culprit, as it crashes on a geodataframe
@KonradBostrom is geopandas also imported in the toolboxes that crash your PRO-instances? This would second my suspicion on geopandas

KonradBostrom

Chris, that's an interesting observation. I do use several opensource GIS libraries in my tool. I might rewrite it to only use base modules and see if that fixes it. Thanks for mentioning.

KonradBostrom

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

Chris_Ste

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.

Robert_LeClair

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

Chris_Ste

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

Hello,

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

RémiBRAUN

**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

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

RémiBRAUN

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...

RémiBRAUN

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

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

CarterHughes

I can confirm this issue is still arising for Pro 3.6.2 with a PYT that uses geopandas. It crashes Pro on the second run.

I rewrote the geopandas dependent code to rely on DuckDB via its spatial extension and it now longer crashes. For context, it is the same spatial analysis (and a little more) that I explored in this article (https://www.linkedin.com/pulse/exploration-geopandas-vs-sedonadb-duckdb-carter-hughes-unnee/) comparing the libraries so it was a quick rewrite from geopandas to DuckDB. Fortunately finding this forum and the attached bug at least diagnosed the root cause having something to do with geopandas gave me the hint to find a workaround.

maxmhuggins

Ich bin auf dasselbe Problem gestoßen, bei dem ein benutzerdefiniertes Python-Geoverarbeitungswerkzeug beim ersten Mal erfolgreich ausgeführt wurde, aber ArcGIS Pro beim zweiten Mal abstürzte. Es gab keine Python-Ausnahme; ArcGIS Pro wurde einfach beendet.

Ich konnte das Problem umgehen, indem ich meinen Verarbeitungs-Code in einen separaten Python-Prozess verschob, sodass die nativen Bibliotheken unabhängig von ArcGIS geladen und entladen werden.

Im Grunde genommen würde mein Toolbox-Skript vor der Lösung so etwas tun,

import arcpy
from custom_package.processor import main_processor

def main():
    inputs_from_arc = arcpy.GetParameterAsText(0)
    output = main_processor(inputs_from_arc)

Das bedeutete, dass die Verarbeitung und alle ihre Abhängigkeiten innerhalb des Python-Prozesses von ArcGIS Pro liefen.

Mit der Lösung startet der Code im Skript einfach einen separaten Prozess mit dem subprocess-Modul von Python. Zum Beispiel,

import arcpy
import subprocess

def main():
    inputs_from_arc = arcpy.GetParameterAsText(0)
    result = subprocess.run(
        [
            path_to_python_env,
            worker_script,
            inputs_from_arc,
        ],
        capture_output=True,
        text=True,
    )

path_to_python_env ist eine Variable, die den Pfad zum Python-Interpreter Ihrer Umgebung enthält, z.B.:

"C:\Users\<USERNAME>\AppData\Local\Programs\ArcGIS\Pro\bin\Python\envs\<custom_environment>\python.exe"

Das worker_script ist der Pfad zu einem separaten Skript, das den ursprünglichen Verarbeitungs-Code enthält, aber die Eingaben aus den sys-Argumenten aufnimmt:

import sys
from custom_package.processor import main_processor

def main():
    inputs_from_arc = sys.argv[1]
    output = main_processor(inputs_from_arc)

if __name__ == "__main__":
    main()

Dies isoliert die Verarbeitungsumgebung von ArcGIS Pro. Jede Ausführung erhält einen frischen Python-Prozess, und wenn der Worker beendet wird, werden seine nativen Bibliotheken und Ressourcen freigegeben, ohne den ArcGIS Pro-Prozess zu beeinträchtigen.

Dies hat in meinem Fall den Absturz beim zweiten Lauf behoben. Ich weiß nicht genau, warum Arc nicht die Fähigkeit hat, ein Python-Skript richtig zu starten und zu beenden, aber hoffentlich hilft dies dabei, Ihre Werkzeuge wieder zum Laufen zu bringen, ohne Ihr Tool komplett neu schreiben zu müssen.

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.