# This Julia process exited with code 9. Press any key to close the terminal

**URL:** <https://discourse.julialang.org/t/this-julia-process-exited-with-code-9-press-any-key-to-close-the-terminal/136098>\
**Category:** New to Julia\
**Created:** [March 9, 2026, 1:51am UTC](https://discourse.julialang.org/t/this-julia-process-exited-with-code-9-press-any-key-to-close-the-terminal/136098 "2026-03-09T01:51:00Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mekapses](https://avatars.discourse-cdn.com/v4/letter/m/b5a626/32.png) [@mekapses](https://discourse.julialang.org/u/mekapses)\
**Post date:** [March 9, 2026, 1:51am UTC](https://discourse.julialang.org/t/this-julia-process-exited-with-code-9-press-any-key-to-close-the-terminal/136098/1 "2026-03-09T01:51:00Z")

</div>

I’m running code that has two potential problem areas: a large dataframe with images, and an analysis which may create arrays that aren’t gc’d. When I run the code, either in VS Code or the REPL i get the unhelpful message that the process was killed. No helpful “out of memory” errors or other errors with a stack trace that would help me figure out what’s going on. What do I do to diagnose what’s going on when I don’t have much to point to? Are there diagnostic calls I can put in my code to help out? Should I be wrapping my loops in a try catch block? Forgive me, but I’m spitballing here…

Thanks,  
–Markos

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [March 9, 2026, 8:34am UTC](https://discourse.julialang.org/t/this-julia-process-exited-with-code-9-press-any-key-to-close-the-terminal/136098/2 "2026-03-09T08:34:14Z")

</div>

It’s very likely your Julia process got killed (with `kill -s 9 $pid`, which is where that exit code comes from) because your system was short on memory. Your system’s kernel logs should tell you exactly what happened (check with e.g. `sudo dmesg -T` and look out for `Out of memory: Killed process ...`).

There’s nothing you can do in your Julia code to prevent that from happening except for allocating less memory. It’s hard to say what exactly needs to be changed from your description (except “make sure every temporary allocation is GC’able”), but maybe give the allocation profiler a go:

> **[Allocation Profiler - Profiling · The Julia Language](https://docs.julialang.org/en/v1/manual/profile/#allocation-profiler)**
>
> The Profile module provides tools to help developers improve the performance of their code. When used, it takes measurements on running code, and produces output that helps you understand how much time is spent on individual line(s). The most common...

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [March 9, 2026, 10:11am UTC](https://discourse.julialang.org/t/this-julia-process-exited-with-code-9-press-any-key-to-close-the-terminal/136098/3 "2026-03-09T10:11:03Z")

</div>

If you are on Linux, run

```bash
htop

```

and monitor the memory usage.

Add a large swap file, like 32 GB.

Put your code in functions, then the memory should be freed when you leave the function.

Just some ideas.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [March 9, 2026, 11:21am UTC](https://discourse.julialang.org/t/this-julia-process-exited-with-code-9-press-any-key-to-close-the-terminal/136098/4 "2026-03-09T11:21:24Z")

</div>

Not sure whether this is viable with your code, but given your description I’d just try adding a

```julia-auto
df = first(df, 100)

```

after you read in the data to see if everything runs as expected with smaller data. You can then also use that to profile your code and check whether there are particular allocation bottlenecks you could optimise.