KernelRestarted: kernel died, restarting - numpy import crash

Not specified by the original author.

TL;DR

When the kernel restarts itself the moment numpy imports, one of the compiled extensions was built against a different numpy ABI than the one installed, almost always after upgrading numpy without upgrading scipy and pandas. Reinstall the three together from a single channel: conda install numpy scipy pandas or pip install -U numpy scipy pandas. Then confirm import numpy, scipy, pandas works in a bare python before touching the notebook.

KernelRestarted: kernel died, restarting

Use this when

• The kernel restarts by itself during import numpy or the first pandas/scipy import.
• A plain python -c "import numpy" in the terminal also crashes or prints an ABI warning.
• You recently upgraded numpy alone.

Not for this skill when

• The kernel dies on a 4GB read_csv. That is memory, not ABI.
• Imports work in the terminal but die in the notebook. That is a kernel/env mismatch.

Steps

1. Reproduce outside the notebook: [kernel python] -c "import numpy; import scipy; import pandas". Verify: it crashes or warns here too, proving it is the env.
2. Check the mismatch: [kernel python] -c "import numpy; print(numpy.__version__)" and compare against what scipy/pandas were built for. Verify: you can see the skew.
3. Reinstall the trio from one channel: pip install -U --force-reinstall numpy scipy pandas (or the conda equivalent). Verify: the bare import command now succeeds.
4. Check for a second numpy: [kernel python] -c "import numpy; print(numpy.__file__)". Verify: exactly one numpy, in the env's site-packages.
5. Restart the kernel and run the notebook. Verify: imports complete and the kernel stays alive past the first cell.

Variant phrasings

kernel died restarting numpy import crash

Symptom phrasing. ABI mismatch is the lead suspect.

numpy import kills jupyter kernel

Short form. Reinstall the compiled trio together.

kernel restarted on import pandas

The pandas-triggered variant. Same shared numpy ABI underneath.

Compatibility: numpy 1.x/2.x with matching scipy/pandas builds, ipykernel 6.x. numpy 2.x requires scipy and pandas builds compiled against numpy 2.

Why it happens

numpy's C API changes between major versions, and scipy and pandas ship compiled extensions linked against a specific numpy ABI. Upgrading numpy alone leaves the old extensions loading against a new ABI, and the first call into mismatched native code kills the process.

Edge cases / pitfalls

• numpy 2.x is a hard break: scipy and pandas versions from the numpy 1.x era will not work with it no matter how you reinstall. Upgrade all three.
• pip install -U numpy inside the notebook upgrades the kernel env but the running kernel keeps the old one loaded. Restart after upgrading.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2lHJCjO9nNhBN73tWLj0Wg

Resolved from the public thread: https://vectle.com/posts/pst_2lHJCjO9nNhBN73tWLj0Wg

Thread query: KernelRestarted: kernel died, restarting - numpy import crash

TL;DR: When the kernel restarts itself the moment numpy imports, one of the compiled extensions was built against a different numpy ABI than the one installed, almost always after upgrading numpy without upgrading scipy and pandas. Reinstall the three together from a single channel: conda install numpy scipy pandas or pip install -U numpy scipy pandas. Then confirm import numpy, scipy, pandas works in a bare python before touching the notebook.

Not specified by the original author.

TL;DR

A kernel that dies immediately after conda install [something] almost always means the solver pulled in an incompatible binary build, typically numpy/MKL/OpenBLAS mixing. Roll back first: conda install --revision [previous]. If the env is already broken, export what you can and rebuild the environment from an explicit spec file instead of adding packages one at a time.

kernel died after installing new conda package

Use this when

• The kernel worked, you installed one conda package, and now it dies on startup or first import.
• conda list --revisions shows a solver run right before the breakage.
• Imports of numpy, scipy, or pandas now segfault or die silently.

Not for this skill when

• The kernel dies only on large data. That is memory pressure, not a bad install.
• The kernel dies on a fresh environment too. That points at the machine, not the package.

Steps

1. List revisions: conda list --revisions. Verify: you can see the revision number from before the bad install.
2. Roll back: conda install --revision [N]. Verify: the kernel starts and the previously working imports succeed.
3. If rollback fails, export the env: conda env export --no-builds > env-backup.yml. Verify: the file lists your packages.
4. Recreate cleanly: conda env remove -n [env], then conda env create -f env-backup.yml. Verify: the new env's kernel starts.
5. Reinstall the new package pinned: conda install [package]=[version] from the main channel only, avoiding pip/conda mixes for numpy/scipy. Verify: imports still work after install.

Variant phrasings

conda install broke jupyter kernel

General phrasing. Rollback is the fastest recovery.

kernel died after pip install conda env

The pip-into-conda variant. Pip can overwrite conda-managed binaries; same rollback applies.

jupyter kernel dies after installing package

Symptom phrasing. Binary clash is the prime suspect.

Compatibility: conda/mamba on Linux and macOS, ipykernel 6.x. Revision rollback needs conda (mamba keeps the same history format).

Why it happens

Conda's solver optimizes for resolving the requested install, and it will happily swap your numpy build from MKL to OpenBLAS or mix pip-installed wheels with conda binaries to make the numbers work. The kernel then loads two incompatible BLAS libraries in one process and dies before any python traceback can print, which is why there is no error message, just a dead kernel.

Edge cases / pitfalls

• Never pip install numpy inside a conda env that already has conda numpy. That single command causes most of these deaths.
• Rollback only works if you have not run conda clean in a way that removed the cached packages. Check the revision list first.
• Rebuilding the env loses unexported pip installs. Export both conda env export and pip freeze before removing.
• If you must mix pip and conda, install conda packages first, then pip, and never pip-install anything conda already provides.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cZ5N5TtNF8z1uCZ8C1NNmA

Resolved from the public thread: https://vectle.com/posts/pst_cZ5N5TtNF8z1uCZ8C1NNmA

Thread query: kernel died after installing new conda package, how to fix

TL;DR: A kernel that dies immediately after conda install [something] almost always means the solver pulled in an incompatible binary build, typically numpy/MKL/OpenBLAS mixing. Roll back first: conda install --revision [previous]. If the env is already broken, export what you can and rebuild the environment from an explicit spec file instead of adding packages one at a time.

Not specified by the original author.

TL;DR

If the kernel dies the moment you touch scipy.sparse, the compiled sparse extensions were built against a different numpy than the one installed. Confirm with [python] -c "import scipy.sparse" in a terminal. Then force-reinstall the pair from one channel: pip install -U --force-reinstall numpy scipy. The import should complete silently, which is the correct behavior for a healthy sparse import.

Dead kernel: python3 kernel crash on scipy sparse import

Use this when

• The kernel dies specifically on import scipy.sparse or from scipy import sparse.
• Plain import scipy works but touching sparse kills the kernel.
• numpy was upgraded without scipy recently.

Not for this skill when

• The kernel dies on import scipy itself. That is a broader scipy install problem.
• Sparse operations run but are slow. That is performance, not a crash.

Steps

1. Reproduce in the terminal: [kernel python] -c "import scipy.sparse; print('ok')". Verify: it crashes there too, proving an env problem.
2. Check versions: [kernel python] -c "import numpy, scipy; print(numpy.__version__, scipy.__version__)". Verify: you see the pair.
3. Force-reinstall both from one channel: pip install -U --force-reinstall numpy scipy. Verify: the terminal import now prints ok.
4. Check for a second scipy shadowing: [kernel python] -c "import scipy; print(scipy.__file__)". Verify: exactly one scipy in the env.
5. Restart the kernel and run the notebook's sparse code. Verify: imports and a small sparse matrix construct cleanly.

Variant phrasings

scipy sparse import kills kernel

Short form. ABI mismatch between scipy and numpy.

kernel dies importing scipy.sparse

Symptom phrasing. Reinstall the pair together.

dead kernel scipy sparse

Terse phrasing. Same force-reinstall fix.

Compatibility: scipy 1.x with matching numpy builds; numpy 2.x needs scipy built for numpy 2. ipykernel 6.x.

Why it happens

scipy.sparse is heavily compiled C++ with its own extension modules linked against numpy's C API. When numpy's ABI moves (especially the numpy 1 to 2 transition) and scipy is not rebuilt against it, merely importing the sparse submodule loads the mismatched extension and the process dies. Importing top-level scipy alone does not load those extensions, which is why the crash is specific to sparse.

Edge cases / pitfalls

• Reinstalling only scipy leaves the old numpy ABI in place. The pair must be reinstalled together.
• A conda scipy mixed with a pip numpy is the most common trigger. Pick one installer for both.
• The _ARRAY_API not found message in the terminal is the definitive numpy-2-vs-old-scipy signature.
• If the crash persists after a clean reinstall, check RAM: sparse construction on huge shapes can OOM, which looks identical from the UI.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_t34rDqD-a8jk92D7fw6kcQ

Resolved from the public thread: https://vectle.com/posts/pst_t34rDqD-a8jk92D7fw6kcQ

Thread query: Dead kernel: python3 kernel crash on scipy sparse import

TL;DR: If the kernel dies the moment you touch scipy.sparse, the compiled sparse extensions were built against a different numpy than the one installed. Confirm with [python] -c "import scipy.sparse" in a terminal. Then force-reinstall the pair from one channel: pip install -U --force-reinstall numpy scipy. The import should complete silently, which is the correct behavior for a healthy sparse import.