Files
lancedb/python/Cargo.toml
T
ChilePiquinandClaude Sonnet 5 4206a727d2 fix(python): close two use-after-free/hang windows in runtime shutdown
The previous commit's shutdown() freed the shared Tokio runtime as soon
as it looked unused (an AtomicPtr swap + Box::from_raw), but callers
only ever held a bare reference into it, with no way to tell shutdown
they were still using it. A concurrent caller could dereference memory
shutdown had already freed.

Switching to an ArcSwapOption<Runtime> so every caller holds an owned
Arc clone for as long as it's using the runtime fixes the
use-after-free, but isn't sufficient on its own, for two reasons:

- future_into_py spawns a task that, once running, spawns a second one
  to do the real work and awaits its JoinHandle. If both nested calls
  independently re-resolved "the current runtime" via get_runtime(), a
  reclaim landing between them could bind the outer and inner task to
  two different runtime instances, permanently stalling the outer task
  if its own runtime was the one torn down while it awaited the inner
  one.

- Runtime::shutdown_timeout gives spawned (non-blocking) tasks no
  grace period at all: a task keeps running until it next yields, then
  is dropped. An outermost caller that only held its Arc for the
  instant it submitted a task let the runtime's reference count fall
  back to baseline immediately, long before the task itself finished,
  so shutdown could reclaim the runtime while a top-level task was
  still genuinely in flight, abandoning it silently.

spawn/spawn_blocking now use Handle::try_current() to pin any nested
call to whatever runtime is already executing it, and the outermost
call moves its Arc clone into the spawned task itself so the reference
count stays elevated for the task's whole lifetime, not just its
submission.

Verified with two new targeted unit tests plus the existing concurrent
stress test, and empirically against a concurrent reproducer built
from this PR's own review feedback: 100+ clean runs with no hangs or
crashes, versus a consistent ~35-55% failure rate beforehand.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-15 05:41:43 -06:00

54 lines
1.5 KiB
TOML

[package]
name = "lancedb-python"
version = "0.39.0-beta.8"
publish = false
edition.workspace = true
description = "Python bindings for LanceDB"
license.workspace = true
repository.workspace = true
keywords.workspace = true
categories.workspace = true
rust-version = "1.91.0"
[lib]
name = "_lancedb"
crate-type = ["cdylib"]
[dependencies]
arc-swap = "1.9"
arrow = { workspace = true, features = ["pyarrow"] }
async-trait.workspace = true
bytes.workspace = true
lancedb.workspace = true
datafusion-common.workspace = true
lance-core.workspace = true
lance-namespace.workspace = true
lance-namespace-impls.workspace = true
lance-io.workspace = true
env_logger.workspace = true
log.workspace = true
# Maturin enables extension-module mode for Python builds. Keeping it out of
# Cargo features lets Rust unit tests link against libpython.
pyo3 = { version = "0.28", features = ["abi3-py310", "chrono", "uuid"] }
chrono.workspace = true
pyo3-async-runtimes = { version = "0.28", features = [
"attributes",
"tokio-runtime",
] }
pin-project.workspace = true
futures.workspace = true
serde.workspace = true
serde_json.workspace = true
snafu.workspace = true
tokio.workspace = true
uuid.workspace = true
libc = "0.2"
[build-dependencies]
pyo3-build-config = { version = "0.28", features = ["abi3-py310"] }
[features]
default = ["remote", "lancedb/aws", "lancedb/gcs", "lancedb/azure", "lancedb/dynamodb", "lancedb/oss", "lancedb/huggingface", "lancedb/cos", "lancedb/goosefs", "lancedb/metrics-otel"]
fp16kernels = ["lancedb/fp16kernels"]
remote = ["lancedb/remote"]