lazygit icon indicating copy to clipboard operation
lazygit copied to clipboard

Lazygit crashes on worktree with bare repo

Open mariuskimmina opened this issue 1 year ago • 18 comments

I have a repo that I cloned with

git clone --bare [email protected]:example/example.git example

And added the main branch as a worktree

git worktree add main

Now, if I go into the main directory and I tree to run lazygit it just crashes after opening for like half a second. I cannot get the full panic because it also leaves my terminal in a messy state.

Lazygit version: commit=5e388e21c8ca6aa883dbcbe45c47f6fdd5116815, build date=2023-08-07T14:05:48Z, build source=binaryRelease, version=0.40.2, os=linux, arch=amd64, git version=2.34.1

(thanks for all the work that went into lazygit, been loving it for a while now)

mariuskimmina avatar Oct 30 '23 06:10 mariuskimmina

Can't reproduce on v0.40.2, so just to confirm the steps needed:

$> git clone [email protected]:jesseduffield/lazygit test
$> cd test
$> git worktree add main
$> cd main
$> lazygit

Is this correct?

mark2185 avatar Oct 31 '23 20:10 mark2185

@mark2185 Interesting, it really doesn't reproduce on the lazygit repo. The repo where I run into this panic is private so I can't just share that. I'll try to find what causes this and create an example that reproduces.

mariuskimmina avatar Nov 01 '23 06:11 mariuskimmina

I did manage to catch the error now:

runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0xc020b80390 stack=[0xc020b80000, 0xc040b80000]
fatal error: stack overflow

runtime stack:
runtime.throw({0xcb82eb?, 0x12fa7c0?})
        /opt/hostedtoolcache/go/1.20.7/x64/src/runtime/panic.go:1047 +0x5d fp=0xc000791e18 sp=0xc000791de8 pc=0x43535d
runtime.newstack()
        /opt/hostedtoolcache/go/1.20.7/x64/src/runtime/stack.go:1105 +0x5bd fp=0xc000791fc8 sp=0xc000791e18 pc=0x44f23d
runtime.morestack()
        /opt/hostedtoolcache/go/1.20.7/x64/src/runtime/asm_amd64.s:574 +0x8b fp=0xc000791fd0 sp=0xc000791fc8 pc=0x465f2b

goroutine 81 [running]:
strings.genSplit({0xc000a4a0a3, 0x31}, {0xddaa58, 0x1}, 0x0, 0xffffffffffffffff?)
        /opt/hostedtoolcache/go/1.20.7/x64/src/strings/strings.go:233 +0x239 fp=0xc020b803a0 sp=0xc020b80398 pc=0x484479
strings.Split(...)

...

mariuskimmina avatar Nov 01 '23 06:11 mariuskimmina

Does the repo have symlinks? Does it crash if the worktree is in a dir outside of the bare clone?

mark2185 avatar Nov 01 '23 06:11 mark2185

This may be related to a bare-repo crash in #3175, which is fixed in (currently open) PR #3183. If you're feeling ambitious, pull my branch in that PR and give it a whirl. Otherwise, retest after that PR lands and is released in hopefully not too long.

jwhitley avatar Dec 28 '23 00:12 jwhitley

I tried it with your PR branch but I still get this crash.

Also, the repo does not have symlinks but it does have additional repos cloned inside it. If I try to use worktrees on the same repo but with a normal clone instead of a bare clone it seems to work fine.

mariuskimmina avatar Dec 28 '23 10:12 mariuskimmina

Thanks for the feedback on the PR. I just tried it with the PR branch, and I'm unable to repro. I used a workflow similar to the one above, but I don't place the worktree inside of the bare repo, but next to it (by using env GIT_DIR=`realpath test` git worktree add main).

Obviously there's a crash here, but at least the basic regular/bare repo plus worktree cases seem to work. I think there's something about the specific private repo that's probably triggering the crash. You mentioned that there are other repos cloned into the first one? Are these submodules, or some more unusual clone-inside-a-clone workflow?

If you're able to discover a repro workflow, perhaps using dummy repositories that mimic the cloning organization you mention, that would be a huge help.

jwhitley avatar Jan 01 '24 00:01 jwhitley

FYI, PR #3183 matured a bit, catching additional edge cases, and has been merged. If you have time, I'd love to know if your issue still reproduces on master. It's plausible that your scenario did eventually get fixed.

jwhitley avatar Feb 12 '24 16:02 jwhitley

I switched jobs and am no longer able to access the repo that caused this issue, so I can't ever say if this is fixed or not. To answer your last question, it was a more unusual clone-inside-clone workflow but even if I removed the clones inside the crash still occured.

From my point of view I would be fine with closing this issue as I won't be able to tell if the issue is fixed or not.

Again thank you for the great work you are doing here, I love using lazygit.

mariuskimmina avatar Feb 14 '24 14:02 mariuskimmina

I'm having this issue right now. Just did a git clone --bare ... and git worktree add master. Without doing bare I was not having this issue at all in the repo.

voylin avatar Aug 10 '24 08:08 voylin

@voylin I’ll see if I can repro tomorrow, my time. What version of lazygit are you using?

jwhitley avatar Aug 13 '24 01:08 jwhitley

@voylin I'm still unable to repro, using lazygit v0.43.1. In samples above, this seemed to be repository dependent somehow. Is this happening for a public repository that you can share here? Alternatively, if you were able to create a public repo that reproduced the problem that would be a big help. Perhaps there's some unusual characteristic of your problem repo that's triggering the crash?

As it is, the underlying code had a major refactor and doesn't crash for similar workflows myself and others have tried in order to reproduce.

jwhitley avatar Aug 13 '24 16:08 jwhitley

@voylin I’ll see if I can repro tomorrow, my time. What version of lazygit are you using?

Using Lazygit 0.43. I was using a public repo. I had this happen for https://github.com/VoylinsGamedevJourney/GoZen_lite. I don't know what went wrong, I don't rule out user error on my side though.

The steps I took were just a git clone bare of the repo, and adding the master branch with git worktree add. I got the problem fixed by just creating a folder with the repo name, using git clone but naming that folder master and in the same folder I added a worktree for the other branch. This works for me.

If you want I could try to replicate the issue and try to get some error logs or something to see if this is an actual issue or just me being dumb in setting up a git bare repo ^^"

voylin avatar Aug 13 '24 22:08 voylin

Thanks @voylin, that's helpful. Let me see if I've got this right:

  1. git clone --bare https://github.com/VoylinsGamedevJourney/GoZen_lite bare
  2. env GIT_DIR=$(realpath bare) git worktree add main – this adds the worktree main alongside the repo bare, i.e. both have the same parent directory.
  3. cd main
  4. lazygit

That workflow isn't crashing for me on lazygit 0.43.1. If you're doing something different when you see the crash, it would be great to know what the exact steps are, since clearly some users hit roadblock here. (and even if the fix is "don't crash, and provide some usage guidance")

Last but not least, I also tried putting a worktree inside of the bare repo directory (which is super weird, since it's the git data directory), but that didn't crash either.

jwhitley avatar Aug 14 '24 18:08 jwhitley

I am getting this error as well, specifically with worktrees. I can provide repro steps and try recloning the directory to verify if there is something specific to the git directory that is different.

christopher-harwell avatar Aug 16 '24 22:08 christopher-harwell

@christopher-harwell That would be great if you can figure out repro steps. So far, no contributors have been able to repro this one.

jwhitley avatar Aug 16 '24 23:08 jwhitley

I'm not able to repro in more than one directory, containing worktrees for a specific repo, but the only difference I've found between difference worktrees is that the directory containing the worktrees that this is crashing in has multiple worktrees in it. The ones that aren't only have 1.

I don't think this should affect anything, though.

I can keep looking today.

christopher-harwell avatar Aug 17 '24 11:08 christopher-harwell