Tim Meehan created SPARK-61260:
----------------------------------
Summary: Raise RecursionError instead of crashing the process on a
deep plan, in the Python client as PySpark does
Key: SPARK-61260
URL: https://issues.apache.org/jira/browse/SPARK-61260
Project: Spark
Issue Type: Bug
Components: Connect
Affects Versions: connect-rust-4.3.0
Reporter: Tim Meehan
A plan with a few thousand chained operations kills the Python process with a
segmentation fault, where PySpark raises a RecursionError that user code can
catch.
{code:python}
from pyspark.sql import SparkSession, functions as F
spark = SparkSession.builder.remote("sc://localhost:15002").getOrCreate()
df = spark.range(10)
for _ in range(2000):
df = df.filter(F.col("id") >= 0)
df.count()
{code}
Against an OSS Spark 4.3.0 Connect server on loopback:
* pyspark-client 4.3.0 raises RecursionError at every depth from 1,000 to
10,000.
* spark-connect-rust master 8768cc4: from 1,000 to 1,500 levels the server
rejects the plan, and the client shows only "[Unknown error] Application error
processing RPC". At 2,000, 3,000, 5,000 and 10,000 levels the process dies with
SIGSEGV.
>From source: building the request recurses through relation_with_references
>and LogicalPlan::to_proto_with (crates/spark-connect/src/plan.rs:842 and :882)
>with no depth limit. At 4ad36945 each level took about 5.5 KB of the 8 MB
>main-thread stack, and with a 64 MB stack (ulimit -s 65536) 1,500 levels did
>not crash. A depth check that raises RecursionError, as PySpark does, would
>turn the crash into an error user code can catch. SPARK-61188 did this for
>progress handlers that run queries without end, not for deep plans.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
