Closed mavaddat closed 2 years ago
mavaddat
commented
2 years ago Also worth noting that Write-PoshDebug (PowerShell) will not execute. It freezes or locks up and requires force termination. I had to resort to oh-my-posh debug which gave me the above output.
JanDeDobbeleer
commented
2 years ago @mavaddat I also noticed this a few times and it also only popped up after I updated to go1.18. The error also originates from go internally, not oh-my-posh logic (made sure to fix that in the previous report). Does it still happen after restarting your terminal ?
JanDeDobbeleer
commented
2 years ago It seems to fail on a line inside go itself, and I'm not quite sure I understand how/why
if len(substr) == 1 {
return bytealg.CountString(s, substr[0])
}That almost implies that bytealg is nil here. I know for a fact that the error started to appear when I made the DirMatchesOneOf part of environment. Before that we never had any issue there. Maybe I can try to move it back out, but that doesn't come even close to explain what's really going on.
JanDeDobbeleer
commented
2 years ago I did some digging and there's nothing that really sparks my attention unless I'm missing something obvious (it can happen, I'm only human). What does happen is that that part of the code is executed in a goroutine to run all segment logic in parallel. It can be that strings.ReplaceAll has a problem with that. I have a fix ready that will run this code synchronous, so it should no longer be executed in parallel.
mattcargile
commented
2 years ago I keep getting this intermittently. It can happen when I Exit-PSSession or Get-ChildItem. I can't repro it at all and it seems random. Though it does seem to occur more often after I "jump" to another directory with ZLocation module and then run ls. Write-PoshDebug does lock up on new sessions. Here is my error.
oh-my-posh fatal error rendering session segment:runtime error: invalid memory address or nil pointer dereference
goroutine 5 [running]:
runtime/debug.Stack()
/opt/hostedtoolcache/go/1.18.0/x64/src/runtime/debug/stack.go:24 +0x65
oh-my-posh/engine.(*Segment).renderText.func1()
/home/runner/work/oh-my-posh/oh-my-posh/src/engine/segment.go:326 +0x58
panic({0xdb0bc0, 0x1866900})
/opt/hostedtoolcache/go/1.18.0/x64/src/runtime/panic.go:838 +0x207
strings.Count({0x0?, 0xe?}, {0xe4a608?, 0xe?})
/opt/hostedtoolcache/go/1.18.0/x64/src/strings/strings.go:47 +0x50
strings.Replace({0x0, 0x53}, {0xe4a608, 0x1}, {0xe4a5f2, 0x1}, 0xffffffffffffffff)
/opt/hostedtoolcache/go/1.18.0/x64/src/strings/strings.go:1003 +0xcf
strings.ReplaceAll(...)
/opt/hostedtoolcache/go/1.18.0/x64/src/strings/strings.go:1037
oh-my-posh/environment.dirMatchesOneOf({0x0?, 0x0?}, {0xc0005320a0, 0x10}, {0xe4d6ad, 0x7}, {0x18d3d40, 0x0, 0xc000284000?})
/home/runner/work/oh-my-posh/oh-my-posh/src/environment/shell.go:737 +0x72
oh-my-posh/environment.(*ShellEnvironment).DirMatchesOneOf(0xc000284000, {0x0, 0x53}, {0x18d3d40, 0x0, 0x0})
/home/runner/work/oh-my-posh/oh-my-posh/src/environment/shell.go:733 +0x125
oh-my-posh/engine.(*Segment).cwdExcluded(0xc0002d0000)
/home/runner/work/oh-my-posh/oh-my-posh/src/engine/segment.go:209 +0xe2
oh-my-posh/engine.(*Segment).shouldIncludeFolder(0xc0002d0000)
/home/runner/work/oh-my-posh/oh-my-posh/src/engine/segment.go:182 +0x36
oh-my-posh/engine.(*Segment).renderText(0xc0002d0000, {0xf80350?, 0xc000284000?})
/home/runner/work/oh-my-posh/oh-my-posh/src/engine/segment.go:332 +0x7b
oh-my-posh/engine.(*Block).renderSegmentsText.func1(0x0?)
/home/runner/work/oh-my-posh/oh-my-posh/src/engine/block.go:88 +0x65
created by oh-my-posh/engine.(*Block).renderSegmentsText
/home/runner/work/oh-my-posh/oh-my-posh/src/engine/block.go:86 +0x98I'm on 7.59.4 using pwsh.exe Version 7.2.2.
EDIT: I did restart my Windows Terminal. I'll report back if it happens again.
EDIT 2: I'm on Windows 20H2 Version 19042.1586.
EDIT 3: Had another segfault. Of note, the error appears in the ending left segment on the default jandedobbeleer theme.
JanDeDobbeleer
commented
2 years ago So my assumption of it being caused by concurrency is wrong. Hmm. I have no clue just yet, haven't seen this on macOS either, could be an issue in the Windows version of golang. If there's a clear reproducible case that would help but it still seems random.
devhawk
commented
2 years ago I'm getting this periodically after upgrading to 7.59.4. Like @mattcargile, seems random and I can't reliably repro.
mattcargile
commented
2 years ago I can more "reliably" produce it running Get-PoshThemes. Let me run procmon trace on it and see what I can find.
EDIT: I can't really easily tell. Maybe it is something with concurrency.
EDIT 2: ~From the procmon trace, I can see one event that stands out. It is a call from oh-my-posh.exe to CreateFileA in KernelBase.dll. The path to the file is C:\WINDOWS\system32\dc9e6cd55143cfaab06d4304fb2c2706ebf3a1194129208d06a3b97811b65cf0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA. procmon gives a result of NAME INVALID. Between two different traces the pattern is this Event with all the AAAAs at the end. Not sure what this means.~ Nevermind.
EDIT 3: I tried adding an Exclusion for Windows Security with Add-MpPreference and that didn't work. Get-PoshThemes is much much faster though!
JanDeDobbeleer
commented
2 years ago I added a wrapper around the function so the error is catched, logged and silenced when happening. Not ideal, but better than crashing for the time being. I want to avoid this becoming a mega thread and buy time to come to a structural solution/understanding.
mattcargile
commented
2 years ago Thanks! The fix has cleared it up for me. I don't even notice error in any of the segments when running Get-PoshThemes like I did before.
DotNetSparky
commented
2 years ago I added a wrapper around the function so the error is catched, logged and silenced when happening. Not ideal, but better than crashing for the time being. I want to avoid this becoming a mega thread and buy time to come to a structural solution/understanding.
I can totally appreciate how you feel--but sometimes, duct-tape is the best temporary solution... 🙃
JanDeDobbeleer
commented
2 years ago I've been going through some related errors and got some understanding of the stack trace and variable references in there. We can see strings.Count((0x0?, Oxe?}, (Oxe4a6087, Oxe?}) which implies that the first string has a nonzero length (0xe) but its data pointer is 0x0 which should not happen. It also explains the error as that string is indeed nil (and actually corrupt). It can originate from race conditions, which can be validated with go test -race ./... but that turns up nothing.
? oh-my-posh [no test files]
? oh-my-posh/cli [no test files]
ok oh-my-posh/color (cached)
ok oh-my-posh/console (cached)
? oh-my-posh/constants [no test files]
ok oh-my-posh/engine 2.830s
ok oh-my-posh/environment (cached)
? oh-my-posh/mock [no test files]
ok oh-my-posh/properties (cached)
? oh-my-posh/regex [no test files]
ok oh-my-posh/segments (cached)
ok oh-my-posh/shell (cached)
ok oh-my-posh/template (cached)So what about the string that's not what it needs to be? You can see it's already corrupt when entering oh-my-posh/environment.dirMatchesOneOf({0x0?, 0x0?}. Let's have a look at that function:
func dirMatchesOneOf(dir, home, goos string, regexes []string) boolMeaning the dir provided is the one that's causing the issue. That one is directly provided via:
func (env *ShellEnvironment) DirMatchesOneOf(dir string, regexes []string) (match bool)In all of the above cases, the provided dir is env.Pwd(), meaning the following function is returning something incorrect:
func (env *ShellEnvironment) Pwd() string {
defer env.trace(time.Now(), "Pwd")
defer func() {
env.log(Debug, "Pwd", env.cwd)
}()
if env.cwd != "" {
return env.cwd
}
correctPath := func(pwd string) string {
// on Windows, and being case sensitive and not consistent and all, this gives silly issues
driveLetter := regex.GetCompiledRegex(`^[a-z]:`)
return driveLetter.ReplaceAllStringFunc(pwd, strings.ToUpper)
}
if env.CmdFlags != nil && env.CmdFlags.PWD != "" {
env.cwd = correctPath(env.CmdFlags.PWD)
return env.cwd
}
dir, err := os.Getwd()
if err != nil {
env.log(Error, "Pwd", err.Error())
return ""
}
env.cwd = correctPath(dir)
return env.cwd
}it could be that in some cases, the value of env.cwd appears to be set but isn't just yet and then causes interactions to fail. I'll try to sync that function so it's blocking, which shouldn't impact much.
This was written to structure my thoughts and for future reference :-)
JanDeDobbeleer
commented
2 years ago @mavaddat @mattcargile @DotNetSparky @devhawk would you mind trying this version? The difference is listed in the related PR, it syncs the Pwd() function and nothing else. I want to see if the above theory stands.
mavaddat
commented
2 years ago @mavaddat @mattcargile @DotNetSparky @devhawk would you mind trying this version?
I have copied oh-my-posh.exe into my $env:LOCALAPPDATA\Programs\oh-my-posh\bin\ overwriting the oh-my-posh.exe and I reloaded the shell. What should I try to verify?
DotNetSparky
commented
2 years ago So far (just a couple minutes of testing), and no errors. But it seemed intermittent before--I'll keep using it and will let you know if it pukes (highly technical term for a seg-fault?)
JanDeDobbeleer
commented
2 years ago @mavaddat use it for a while. I want to see if this fixes the issue as well. As that's the clean fix (if confirmed).
Thanks @DotNetSparky
DotNetSparky
commented
2 years ago @JanDeDobbeleer - I'll continue testing it over the weekend, but just wanted to let you know that, despite using the console a lot for two hours now, no errors so far!
mattcargile
commented
2 years ago Run Get-PoshThemes and look for the error in all the output.
mavaddat
commented
2 years ago After using it for a bit, I found the following command seems to relaibly crash oh-my-posh.exe:
Get-ChildItem -Path . -Depth 0 -Directory | Sort-Object -Property CreationTimeUtc -Descending | Select-Object -First 1However, I am not sure this is related to the above symptoms (the seg fault reported in the op). I believe that the oh-my-posh.exe has a hard time digesting the Microsoft.PowerShell.Core\FileSystem::[…] path, because if I do Set-Location $env:USERPROFILE (i.e., cd ~), then the rich shell prompt is visible again.
mattcargile
commented
2 years ago I'm trying the new build and haven't received any errors yet. I tried @mavaddat's repro above and couldn't recreate the error. On another note, the new build doesn't support Registry paths or UNC paths. Get-PoshThemes doesn't fail anymore though.
JanDeDobbeleer
commented
2 years ago @mattcargile I'll rebase as it should since that wasn't changed. @mavaddatsure you're using the provided build?
mavaddat
commented
2 years ago @mavaddat sure you're using the provided build?
Yes, oh-my-posh.exe --version returns 7.60.0.
@mattcargile @JanDeDobbeleer I am sorry, I missed the final piped part of the error producing code Set-Location.
Get-ChildItem -Path . -Depth 0 -Directory | Sort-Object -Property CreationTimeUtc -Descending | Select-Object -First 1 | Set-LocationThe oh-my-posh.exe has to be copied and pasted. 7.60 doesn't include the fix as far as I know. I had to switch to that version recently today because the build in this Issue had issues with UNC.
mavaddat
commented
2 years ago oh-my-posh.exe debug | Set-Clipboard gives:
debugmavaddat
commented
2 years ago The
oh-my-posh.exehas to be copied and pasted.7.60doesn't include the fix as far as I know.
Oops, thanks @mattcargile . I routinely run winget upgrade --all which obviously erases the custom oh-my-posh.exe build. D'oh.
mavaddat
commented
2 years ago That being said, with the custom version, I am able to repro the Set-Location weirdness.
Get-ChildItem -Path . -Depth 0 -Directory | Sort-Object -Property CreationTimeUtc -Descending | Select-Object -First 1 | Set-Location
cd ~
mattcargile
commented
2 years ago I routinely run
winget upgrade --allwhich obviously erases the customoh-my-posh.exebuild. D'oh.
I see. I've always been afraid to run winget for everything. Sorry a bit off topic but do you get errors on certain upgrades for dupes?
mattcargile
commented
2 years ago @mavaddat , that appears to be a different issue. Do you have a link in your home directory to a UNC path? That behavior is the same when you cd into a UNC directory when on the build on this Issue.
JanDeDobbeleer
commented
2 years ago Any update on crashing behaviour? If that's fixed I'm merging this solution.
DotNetSparky
commented
2 years ago I have not seen any crashes since using your test version, so you have my vote :)
github-actions[bot]
commented
7 months ago This issue has been automatically locked since there has not been any recent activity (i.e. last half year) after it was closed. It helps our maintainers focus on the active issues. If you have found a problem that seems similar, please open a discussion first, complete the body with all the details necessary to reproduce, and mention this issue as reference.
Code of Conduct
What happened?
Ran the following command to update, then received seg fault error from
oh-my-poshfor every command thereafter:Here is the seg fault error:
Similar to #1586
Theme
Modified from
jandedobbeleer.omp.json.What OS are you seeing the problem on?
Windows
Which shell are you using?
powershell
Log output