Skip to content

fix(lambda): use PyPI wheels for numpy/pandas on AL2023 layer builds … - #3398

Merged
kukushking merged 1 commit into
mainfrom
fix/lambda-layer-al2023-numpy-pandas-abi-mismatch
Jul 15, 2026
Merged

fix(lambda): use PyPI wheels for numpy/pandas on AL2023 layer builds …#3398
kukushking merged 1 commit into
mainfrom
fix/lambda-layer-al2023-numpy-pandas-abi-mismatch

Conversation

@kukushking

Copy link
Copy Markdown
Collaborator

Feature or Bugfix

  • Bugfix

Detail

  • The managed Lambda layer AWSSDKPandas-Python312:29 (and Python 3.13/3.14 equivalents) SIGSEGVs on any pandas datetime64 construction — df["t"] = datetime.datetime.now(), pd.to_datetime(...), or any awswrangler internal timestamp casting. Crash originates in pandas/core/construction.py:503 ensure_wrapped_if_datetimelike, on Lambda it surfaces as Runtime.ExitError: signal: segmentation fault on every invocation that touches a datetime value.
  • Root cause: pip install --no-binary numpy,pandas under default build isolation on AL2023 produces a pandas binary linked against a numpy ABI that doesn't match the numpy 2.5.x wheel resolved separately in the same layer. Confirmed by reproducing the exact stack trace in public.ecr.aws/lambda/python:3.12 with --no-binary numpy,pandas, and confirming the same versions from PyPI wheels work cleanly.
  • The --no-binary flag was originally required on AL2 (glibc 2.26) because PyPI's manylinux_2_28 wheels wouldn't load. AL2023 (glibc 2.34) satisfies manylinux_2_28, so the flag is no longer needed for Python 3.12/3.13/3.14 builds and is actively causing the ABI mismatch.
  • Fix: drop PIP_NO_BINARY env and --no-binary-package numpy/pandas from uv sync in Dockerfile.al2023; gate the --no-binary numpy,pandas flag on build-lambda-layer.sh via /etc/os-release so only AL2 (VERSION_ID="2") keeps source builds. AL2 py3.10/3.11 verified unaffected — its older numpy 2.4.x source build works correctly.

Relates

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

…3393)

Building numpy/pandas from source without pinning the build-time numpy
to the runtime numpy produces a pandas binary linked against a numpy
ABI that doesn't match the numpy 2.5.x shipped alongside it, causing
SIGSEGV on datetime64 construction paths (e.g. df["t"] = datetime.now(),
pd.to_datetime(...)).

AL2023 has glibc 2.34, which satisfies the manylinux_2_28 tag PyPI
ships numpy/pandas wheels under, so drop the source-build override on
that Dockerfile and gate the flag in build-lambda-layer.sh on
/etc/os-release. AL2 (glibc 2.26) can't load manylinux_2_28 and its
older numpy 2.4.x source build is unaffected, so keep source builds
there.

Verified in a public.ecr.aws/lambda/python:3.12 container that the
segfault reproduces without the fix and disappears with it; AL2
py3.11 source-built numpy 2.4.6 + pandas 3.0.3 continue to work.
@kukushking kukushking self-assigned this Jul 7, 2026
@kukushking
kukushking merged commit 8a5101a into main Jul 15, 2026
31 checks passed
@kukushking
kukushking deleted the fix/lambda-layer-al2023-numpy-pandas-abi-mismatch branch July 15, 2026 09:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AWSSDKPandas-Python312:29 managed layer SIGSEGVs on datetime64 (pandas 3.0.3 / numpy 2.5.0)

2 participants