# How can I find out why julia crashed?

**URL:** <https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467>\
**Category:** General Usage\
**Tags:** question, debug, crash\
**Created:** [August 21, 2024, 10:20pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467 "2024-08-21T22:20:13Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![maxfreu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maxfreu/32/17468_2.png) [@maxfreu](https://discourse.julialang.org/u/maxfreu)\
**Post date:** [August 21, 2024, 10:20pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/1 "2024-08-21T22:20:13Z")

</div>

Hi! I’m working with julia in vscode. A couple of times a day it crashes. By crashing I mean the julia repl closes and I’m dropped into the terminal. Sometimes I get a short glimpse of some error printout from the linux kernel before it vanishes and I don’t know how to restore it. Most often I crash julia due to: Bugs in Makie that call some non-existent library function, ctrl-c ing a bit too often in a row while some big data is loading, accidentally filling RAM, using distributed in ways no developer ever anticipated, ctrl-c ing while threaded code executes, … My feeling is that julia should throw errors, but not crash. So how can I find out the reasons why? Do I have to use a debug build? Or how can I make the kernel error messages display a little longer, so that I at least know whether it was OOM or a segfault. Your advice is highly welcome! In return I can offer advice on how to crash julia 😉

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [August 21, 2024, 10:22pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/2 "2024-08-21T22:22:55Z")

</div>

If it’s oom I think it should be logged in dmesg.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [August 21, 2024, 10:25pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/3 "2024-08-21T22:25:53Z")

</div>

> [@maxfreu](#):
>
> how can I find out the reasons why?

Your question is not focused enough for a good answer. Try opening a new thread given a specific example.

> [@maxfreu](#):
>
> make the kernel error messages display

As @jar1 implies, run `dmesg`. Perhaps you need to do it as root user.

I like the `-x` and `-w` options for `dmesg`, `-x` shows the type of each message, while `-w` makes `dmesg` print each new message as it is created, instead of exiting after printing all existing messages.

> [@maxfreu](#):
>
> julia should throw errors, but not crash

Yeah, when that happens, there’s a bug, either a Julia bug, a Julia VS Code extension bug, or a package bug, etc.

---

<div class="post-metadata">

**Author:** ![maxfreu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maxfreu/32/17468_2.png) [@maxfreu](https://discourse.julialang.org/u/maxfreu)\
**Post date:** [August 21, 2024, 11:14pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/4 "2024-08-21T23:14:26Z")

</div>

> [@nsajko](#):
>
> Your question is not focused enough for a good answer.

I’m not necessarily interested in exact solutions to specific problems. More in a strategy / workflow that enables me to pinpoint the root cause within julia. The dmesg hint was already good, found a julia segfault right away. But how do I know where it came from?

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [August 22, 2024, 10:08am UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/5 "2024-08-22T10:08:14Z")

</div>

> [@maxfreu](#):
>
> But how do I know where it came from?

A segfault may, depending on your system setup, result in a coredump. These are sometimes available via `coredumpctl`. Though that’s possibly not the best way to debug a julia crash.

There are various things to suggest when debugging Julia:

- try from REPL instead of from VS Code
- try nightly instead of release
- try an assert build (can be downloaded from Github)
- more debugging info: start `julia` with `-g2`
- disable `@inbounds`: start `julia` with `--check-bounds=yes`
- the Julia developers like to have an `rr` trace to be able to debug a julia crash more easily. `julia` has built-in support for that, on Linux, with `julia --bug-report=rr`. See [Reporting and analyzing crashes (segfaults) · The Julia Language](https://docs.julialang.org/en/v1.12-dev/devdocs/backtraces/) and [Julia 1.5 Feature Preview: Time Traveling (Linux) Bug Reporting](https://julialang.org/blog/2020/05/rr/)
- `git bisect`

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [August 22, 2024, 10:13am UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/6 "2024-08-22T10:13:34Z")

</div>

> [@maxfreu](#):
>
> I’m not necessarily interested in exact solutions to specific problems. More in a strategy / workflow that enables me to pinpoint the root cause within julia.

This is really a bag-of-tricks kind of situation. So it’s best to learn by solving specific issues.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [August 22, 2024, 12:56pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/7 "2024-08-22T12:56:31Z")

</div>

> [@nsajko](#):
>
> Your question is not focused enough for a good answer. Try opening a new thread given a specific example.

This _is_ attempting to get to a specific example — when Julia crashes in VS Code the window closes so quickly you don’t see the error message. If you can’t see the error message, you can’t tell why it crashed. There are a few cases (like OOM) where Julia doesn’t print out much detail, but most crashes do show an exception and stacktrace.

I don’t know if it’s possible to preserve the terminal window in VS Code after the process closes, but that’s what I see as the core ask here. It’s something I’d like myself, in fact!

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [August 22, 2024, 1:31pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/8 "2024-08-22T13:31:56Z")

</div>

> [@mbauman](#):
>
> that’s what I see as the core ask here

If so (not sure), this should be moved to the Tooling → VS Code category. But I think that was just an example in the OP, so it may be best to open a new post about that issue.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [August 22, 2024, 1:56pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/9 "2024-08-22T13:56:15Z")

</div>

The very first thing I would do is try to figure out the minimal amount of code required to produce the crash and be specific.

If loading package X.jl and running function `foo` causes the crash, is it specific to a particular version of package X or can I narrow it down to a smaller subfunction?

Once we have the reproducer we can try reproduce the problem under a debugger such as `gdb` or obtain a `rr` trace.

---

<div class="post-metadata">

**Author:** ![maxfreu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maxfreu/32/17468_2.png) [@maxfreu](https://discourse.julialang.org/u/maxfreu)\
**Post date:** [August 23, 2024, 8:26am UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/10 "2024-08-23T08:26:05Z")

</div>

I’m now using a standalone repl, because there I get a minimal error printout after the crash. So this topic could indeed be moved to tooling / vscode - having the terminal window open after a crash is maybe a change that could be implemented there.

> [@mkitti](#):
>
> The very first thing I would do is try to figure out the minimal amount of code required to produce the crash and be specific.

Yes, and having the stacktrace after the crash (if it prints) helps with that. However, often julia crashes completely randomly half an hour into a session. For example after executing a cell again a little later, or on typing `?Legend` for Makie docs… things that usually work, but once in a while don’t. Getting a reproducer for those is hard.

---

<div class="post-metadata">

**Author:** ![xgdgsc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xgdgsc/32/608_2.png) [@xgdgsc](https://discourse.julialang.org/u/xgdgsc)\
**Post date:** [August 23, 2024, 9:02am UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/11 "2024-08-23T09:02:37Z")

</div>

Install tmux and use persistent mode as [Remote Development · Julia in VS Code (julia-vscode.org)](https://www.julia-vscode.org/docs/stable/userguide/remote/#Persistent-server-sessions) You’ ll be able to see the crash messages.

You are likely also seeing [ctrl+c presses crash repl · Issue #3676 · julia-vscode/julia-vscode (github.com)](https://github.com/julia-vscode/julia-vscode/issues/3676)

[Long running tasks crash Julia session · Issue #3674 · julia-vscode/julia-vscode (github.com)](https://github.com/julia-vscode/julia-vscode/issues/3674)

---

<div class="post-metadata">

**Author:** ![maxfreu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maxfreu/32/17468_2.png) [@maxfreu](https://discourse.julialang.org/u/maxfreu)\
**Post date:** [August 28, 2024, 1:25pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/12 "2024-08-28T13:25:20Z")

</div>

Ok, so just now it crashed again during evaluation of a cell that has worked 10+ times flawlessly. Thanks to the terminal-repl I got this printout:

```julia
[1910653] signal (11.1): Segmentation fault
in expression starting at /home/max/dr/extract_sentinel_pixels/plot_recipies/plot_averaged_timeseries.jl:12
gc_mark_outrefs at /cache/build/builder-amdci4-0/julialang/julia-release-1-dot-10/src/gc.c:2517 [inlined]
gc_mark_and_steal at /cache/build/builder-amdci4-0/julialang/julia-release-1-dot-10/src/gc.c:2746
gc_mark_loop_parallel at /cache/build/builder-amdci4-0/julialang/julia-release-1-dot-10/src/gc.c:2885
jl_gc_mark_threadfun at /cache/build/builder-amdci4-0/julialang/julia-release-1-dot-10/src/partr.c:142
start_thread at /lib64/libpthread.so.0 (unknown line)
clone at /lib64/libc.so.6 (unknown line)
Allocations: 506203251 (Pool: 506080440; Big: 122811); GC: 194
Segmentation fault (core dumped)

```

I assume this alone is not enough information to locate the exact error source. Would an assert build help here? And @nsajko can you explain what that is? How much does it impact performance?

To my impression the number of segfaults has increased when going from 1.10 to 1.10.4, but as I also updated lots of packages at the same time that’s probably no clear indication.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [August 28, 2024, 1:59pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/13 "2024-08-28T13:59:56Z")

</div>

This seems to be a bug in Julia’s garbage collector (GC). Try reporting a bug.

> [@maxfreu](#):
>
> Would an assert build help here?

Don’t know. Try it if time allows.

> [@maxfreu](#):
>
> can you explain what that is?

It’s a build configuration of Julia, enabling some assertions. When the Julia implementation detects certain unexpected states, it errors with a debug message:

[https://docs.julialang.org/en/v1.12-dev/devdocs/build/build/](https://docs.julialang.org/en/v1.12-dev/devdocs/build/build/)

I sometimes build an assert build locally using `make FORCE_ASSERTIONS=1 LLVM_ASSERTIONS=1`.

Assert builds for recent Julia commits are available from Github. Go to the Git history, listing all commits, select the checks for a commit (beneath the title of the commit), select “details” for “build”, select “build YOUR\_PLATFORM”, select “artifacts”, downloads the archive, unpack it, run julia from where you unpacked it.

NB: Julia developers seems to really like having an `rr` trace for a crash: [Reporting and analyzing crashes (segfaults) · The Julia Language](https://docs.julialang.org/en/v1.12-dev/devdocs/backtraces/#Other-generic-segfaults-or-unreachables-reached). Not sure if that’s a practical option for you, but the procedure is:

1. start julia with `julia --bug-report=rr`, while connected to the network, on Linux
2. cause a crash
3. wait for the trace to upload
4. post a bug report with the link

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [August 28, 2024, 2:10pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/14 "2024-08-28T14:10:03Z")

</div>

> [@nsajko](#):
>
> This seems to be a bug in Julia’s garbage collector (GC). Try reporting a bug.

Not necessarily — pretty much any time you inadvertently corrupt Julia’s internals, it’ll end up tripping up the GC.

The two most common ways to corrupt internals is with bad `@inbounds` or bad `@ccall`s (or perhaps `pointer` without `GC.@preserve`). I wouldn’t expect assertions to catch this, but starting Julia with `--check-bounds=yes` is a great start.

---

<div class="post-metadata">

**Author:** ![maxfreu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maxfreu/32/17468_2.png) [@maxfreu](https://discourse.julialang.org/u/maxfreu)\
**Post date:** [August 29, 2024, 7:47pm UTC](https://discourse.julialang.org/t/how-can-i-find-out-why-julia-crashed/118467/15 "2024-08-29T19:47:37Z")

</div>

I must have overread the `--check-bounds=yes` and `--bug-report=rr` suggestions and will try them out. Also now had the time to look into Keno’s blog post. Thanks again for the replies!