rgit unexpectedly restarts

[paberr]

I have just setup rgit using Docker and was playing around with it. It correctly shows my git repositories and the summary also lists my commits and branches.

However, as soon as I try to get information on a specific commit or file, the docker container crashes and restarts. Going through the tree directory structure works – only accessing a file crashes rgit.

I am trying to debug the issue but the logs do not seem to give much of a hint on what's going on. I've attached the logs for two different actions here. I waited for rgit to restart and then performed the relevant action.

Is there a way to get better logging output?

Accessing a commit

2025-03-14T11:19:39.581984Z  INFO ThreadSafeRepository::open():open_from_paths():gix_odb::Store::at(): gix_odb::store_impls::dynamic::init: close time.busy=108µs time.idle=1.74µs
2025-03-14T11:19:39.582029Z  INFO ThreadSafeRepository::open():open_from_paths(): gix::open::repository: close time.busy=365µs time.idle=1.05µs
2025-03-14T11:19:39.582039Z  INFO ThreadSafeRepository::open(): gix::open::repository: close time.busy=498µs time.idle=4.95µs
2025-03-14T11:19:39.582271Z  INFO web{request_id="aca2457a-9b80-4445-ba68-453262515dc8"}:repo{repo_path="/git/repo" branch=None}: rgit::git: close time.busy=196µs time.idle=764µs
2025-03-14T11:19:39.583764Z  INFO fetch_diff_and_stats{highlight=true}:gix_index::State::from_tree(): gix_index::init::from_tree: close time.busy=347µs time.idle=1.70µs
2025-03-14T11:19:39.584379Z  INFO fetch_diff_and_stats{highlight=true}:gix_index::State::from_tree(): gix_index::init::from_tree: close time.busy=341µs time.idle=3.04µs
2025-03-14T11:19:41.908513Z  INFO rgit: Priming highlighters...
2025-03-14T11:20:01.410158Z  INFO rgit: Server starting up...

Accessing a file

2025-03-14T11:24:28.417447Z  INFO web{request_id="820fbd58-9d73-4654-959d-eb45951bfa20"}:repo{repo_path="/git/repo" branch=None}: rgit::git: close time.busy=51.7µs time.idle=4.30µs
2025-03-14T11:24:30.592960Z  INFO rgit: Priming highlighters...

[w4]

Can you access the plain variant of the file views by appending ?raw=true to the URL? If so, it's likely an issue with treesitter. The exit code of the binary should give a little bit more info about the problem.

[paberr]

Sure, I just tested it. It works when I append the ?raw=true parameter. And the exit code when crashing is 132.

I tried to see if that's an error code you use yourself but couldn't find it. That might indicate that it comes from the OS due to an illegal instruction (possibly, the Docker image is compiled with some CPU extensions enabled that my CPU doesn't support?).

Edit: I just checked the binary and it seems to use AVX instructions, which my CPU doesn't support. For completeness: I'm running rgit on my NAS which has an Intel Celeron J3455. The J3455 supports SSE4.2 but does not support AVX.

[paberr]

I'm running it in a custom build now and got some more info:

Illegal instruction (core dumped)
traps: tokio-runtime-w[18032] trap invalid opcode ip:5611e3f0b752 sp:7f33a27fa3a0 error:0 in rgit[5611e3ed3000+6e5000]

After running the binary in gdb, indeed I get the following:

0x0000555555688752 in v_htmlescape::ranges::avx::b_escape

It looks like the build process currently builds the code using the native target of the build machine instead of the more generic x86_64-unknown-linux-gnu. This target has a default target cpu of x86-64, which only enables extensions supported by all x86-64 CPUs.

I'll look into the build process to see if I can change that easily.

[w4]

Ah, v_htmlescape is an interesting one. It's specifically the macro invocation in the build script that is causing this because the build script currently runs on github runners. https://github.com/zzau13/v_escape/blob/master/v_htmlescape/build.rs#L8

docker build on your Celeron should perform the correct feature detection. Adding RUSTFLAGS="-C target-cpu=..." would also work. There's already an open issue on the v_htmlescape issue to move to runtime feature detection

[paberr]

I played a bit around with the docker build script, effectively setting the target CPU to x86-64. But since the relevant line in v_htmlescape is a runtime check in the build script, it seems to override my setting.

Building it on the Celeron itself also isn't straightforward as it fails with error: unable to load seccomp BPF program: Invalid argument. I didn't have time to look into it deeply yet, but a quick test with NIX_INSTALLER_EXTRA_CONF='filter-syscalls = false' seemed not to work either (contrary to what you can commonly find related to that error).