Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VS CODE terminal cannot start, after udpate oh-my-zsh #12331

Closed
yingzi17 opened this issue Apr 7, 2024 · 26 comments
Closed

VS CODE terminal cannot start, after udpate oh-my-zsh #12331

yingzi17 opened this issue Apr 7, 2024 · 26 comments
Assignees
Labels
Area: core Issue or PR related to core parts of the project Bug Something isn't working

Comments

@yingzi17
Copy link

yingzi17 commented Apr 7, 2024

Describe the bug

when i update oh-my-zsh, i cannot start a terminal window in vscode

17:14:11 段错误(吐核)

Steps to reproduce

1.update oh-my-zsh,
2. i cannot start a terminal window in vscode

Expected behavior

how can i fix it

Screenshots and recordings

No response

OS / Linux distribution

linux

Zsh version

zsh 5.0.2 (x86_64-redhat-linux-gnu)

Terminal emulator

vscode

If using WSL on Windows, which version of WSL

None

Additional context

No response

@taekinkim
Copy link
Contributor

You can avoid the problem temporarily.

cd ~/.oh-my-zsh
git checkout 6dfa9507ce0eb0f4d386bd03268e33943ea55c0f

and then, try again.

@carlosala
Copy link
Member

Hi! I can't reproduce any issue. What's exactly happening? Could you share a screen recording or further describe the issue? @taekinkim does it happen to you as well?

@carlosala carlosala self-assigned this Apr 8, 2024
@taekinkim
Copy link
Contributor

@carlosala
Yes, it happens to me as well.

I have worked in vscode with remote-ssh connection.
I could open my repository in vscode, but I couldn't open the terminal window in vscode.
When I try to open a terminal window, the terminal window appears and then it disappears immediately.
core.98912 file is created, and I tried to run gdb.

$ gdb /bin/zsh core.98912
GNU gdb (GDB) Red Hat Enterprise Linux 10.2-5.el7
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /bin/zsh...
Reading symbols from .gnu_debugdata for /usr/bin/zsh...
(No debugging symbols found in .gnu_debugdata for /usr/bin/zsh)
[New LWP 98912]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `zsh'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f0cdc4a0eaa in get_widget () from /usr/lib64/zsh/5.0.2/zsh/zle.so
Missing separate debuginfos, use: debuginfo-install zsh-5.0.2-34.el7_8.2.x86_64
(gdb) 

The server is like:

➜ uname -a
Linux 5217453785bc 3.10.0-1160.53.1.el7.x86_64 #1 SMP Fri Jan 14 13:59:45 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
➜  .oh-my-zsh git:(master) pwd
/home1/myid/.oh-my-zsh
➜  .oh-my-zsh git:(master) git log
commit bf713e2c112ee1f0daf10deffa1215c982513f9b (HEAD -> master, origin/master)
Author: David Chin <prehensilecode@users.noreply.github.com>
Date:   Sun Apr 7 01:23:19 2024 +0800
...

@taekinkim
Copy link
Contributor

I have tried with several omz commits.
I found the commit that cause the problem: ec1afe9

@mcornella
Copy link
Member

@CherryYang05 reported in #12344:

Describe the bug

As beginning I used VSCode remote SSH to connect the server, when I open a directory which includes the '.git' dir, it flashed in a short time. Then I put the "zsh" command in my terminal(not in VSCode terminal), it displayed "core dumped". And when I enter a dir without a '.git' dir after I enter a dir including a '.git' dir(e.g. 'cd git_repo' and then 'cd ..'), it also display the omz's git prompt like '~(master)'. Actually, my home dir does not include '.git' dir. I tried a lot, when I open a directory without '.git' dir, it worked as it was. I guess maybe it is my server's problem, but I copy the '.oh-my-zsh' dir(lower version) from other server, it worked without any errors. The error above may be caused by some bugs in the latest version.

Steps to reproduce

1. open a dir including '.git' dir in vscode

2. OR input 'zsh' command in a dir including '.git' dir in your own terminal

Expected behavior

1. in vscode, the terminal flashed and quit

2. in your own terminal, it displayed 'core dumped'

Screenshots and recordings

No response

OS / Linux distribution

CentOS 7

Zsh version

5.0.2

Oh My Zsh version

master(605d766)

Terminal emulator

VSCode terminal & Termius

If using WSL on Windows, which version of WSL

None

Additional context

No response

@mcornella
Copy link
Member

Can you reproduce the issue with tracing enabled (running zsh as zsh -xv, or within a shell, running set -xv) and capture the output when you enter a directory that makes this core dump happen?

@mcornella mcornella self-assigned this Apr 10, 2024
@mcornella mcornella added Bug Something isn't working Area: core Issue or PR related to core parts of the project labels Apr 10, 2024
@taekinkim
Copy link
Contributor

@mcornella
I guess that the problem is related with a git repository directory.
When I run zsh in a git repo directory, the core file is created.
But when I run zsh in other directory, the core file is NOT created and it is executed well.

The last part of results of zsh -xv is following:

...
+_zsh_autosuggest_bind_widget:1> typeset -gA _ZSH_AUTOSUGGEST_BIND_COUNTS
+_zsh_autosuggest_bind_widget:3> local 'widget=where-is'
+_zsh_autosuggest_bind_widget:4> local 'autosuggest_action=modify'
+_zsh_autosuggest_bind_widget:5> local 'prefix=autosuggest-orig-'
+_zsh_autosuggest_bind_widget:7> local -i bind_count
+_zsh_autosuggest_bind_widget:10> case user:_zsh_highlight_widget_orig-s0.0000060000-r30531-where-is (user:_zsh_autosuggest_(bound|orig)_*)
+_zsh_autosuggest_bind_widget:10> case user:_zsh_highlight_widget_orig-s0.0000060000-r30531-where-is (user:*)
+_zsh_autosuggest_bind_widget:18> _zsh_autosuggest_incr_bind_count where-is
+_zsh_autosuggest_incr_bind_count:1> typeset -gi 'bind_count=1'
+_zsh_autosuggest_incr_bind_count:2> _ZSH_AUTOSUGGEST_BIND_COUNTS[$1]=1 
+_zsh_autosuggest_bind_widget:19> zle -N autosuggest-orig-1-where-is _zsh_highlight_widget_orig-s0.0000060000-r30531-where-is
+_zsh_autosuggest_bind_widget:42> eval '_zsh_autosuggest_bound_1_where-is() {
		_zsh_autosuggest_widget_modify autosuggest-orig-1-where-is $@
	}'
+_zsh_autosuggest_bind_widget:47> zle -N -- where-is _zsh_autosuggest_bound_1_where-is
+_zsh_highlight_main__precmd_hook:3> setopt localoptions
+_zsh_highlight_main__precmd_hook:4> eval '[[ -o warnnestedvar ]]'
+(eval):1> [[ -o warnnestedvar ]]
+_zsh_highlight_main__precmd_hook:8> _zsh_highlight_main__command_type_cache=( ) 
+zsh:1> git_prompt_info
+git_prompt_info:1> setopt localoptions noksharrays
+git_prompt_info:2> [[ -n '' ]]
�[?1h�=+_omz_async_callback:1> emulate -L zsh
+_omz_async_callback:3> local 'fd=12'
+_omz_async_callback:4> local 'err=hup'
+_omz_async_callback:6> [[ -z hup || hup == hup ]]
+_omz_async_callback:8> local 'handler=_omz_git_prompt_info'
+_omz_async_callback:11> local 'old_output='
+_omz_async_callback:14> IFS='' +_omz_async_callback:14> read -r -u 12 -d '' '_OMZ_ASYNC_OUTPUT[_omz_git_prompt_info]'
+_omz_async_callback:17> [[ '' != %{�\[01;34m%}git:\(%{�\[31m%}add/region%{�\[34m%}\) %{�\[33m%}%1{✗%}%{�\[00m%} 
 ]]
+_omz_async_callback:18> zle reset-prompt

(and then segmentation fault occured.)

If I change the code:

if zstyle -T ':omz:alpha:lib:git' async-prompt; then

into:

diff --git a/lib/git.zsh b/lib/git.zsh
index c426597..9d19b0d 100644
--- a/lib/git.zsh
+++ b/lib/git.zsh
@@ -38,7 +38,7 @@ function _omz_git_prompt_info() {
 }
 
 # Enable async prompt by default unless the setting is at false / no
-if zstyle -T ':omz:alpha:lib:git' async-prompt; then
+if zstyle -t ':omz:alpha:lib:git' async-prompt; then
   function git_prompt_info() {
     setopt localoptions noksharrays
     if [[ -n "$_OMZ_ASYNC_OUTPUT[_omz_git_prompt_info]" ]]; then

zsh is executed without any problem.

@carlosala
Copy link
Member

Could you try in master branch, but doing git revert b43b84abc77850a3734c127c38afdd7cf7739dc6? Do you still reproduce the same issue?

@taekinkim
Copy link
Contributor

@carlosala
I tried in master branch, and I've got the core file.
If I git checkout b43b84abc77850a3734c127c38afdd7cf7739dc6, the problem is gone.

@carlosala
Copy link
Member

So, in that moment (b4...) it was working as expected, right?

@taekinkim
Copy link
Contributor

taekinkim commented Apr 11, 2024

Yes, it is right.

@carlosala
Copy link
Member

carlosala commented Apr 11, 2024

Could you try in master but reverting that commit? I'm certain it should to be that one.

@taekinkim
Copy link
Contributor

taekinkim commented Apr 11, 2024

$ git checkout master
$ git revert ec1afe9
$ zsh
# error

$ git checkout master
$ git revert b43b84a
$ zsh
# ok. no error 

The commit with problem is ec1afe9, not b43b84a.

FIX: I wrote the command history the other way around.

@carlosala
Copy link
Member

carlosala commented Apr 11, 2024

I'll try to bisect. Which OS and version reproduces the issue?

EDIT: I see that centos 7 reproduces it👍🏻

@carlosala
Copy link
Member

carlosala commented Apr 11, 2024

@taekinkim is it reproducible as well if you just ssh to the server directly, or the segmentation fault only happens in vscode?
I wasn't able to reproduce absolutely any issue in centos 7 (under docker)

@taekinkim
Copy link
Contributor

taekinkim commented Apr 12, 2024

I also used docker container. I did ssh-connect to the container in vscode.
I tried zsh both directly and in vscode, and I've got segmentation fault in both.

Here is the segmentation fault in server connected directly:
스크린샷 2024-04-12 오전 11 07 20

@carlosala
Copy link
Member

carlosala commented Apr 12, 2024

I'm still not able to do so. Not sure what's missing. Could you send a screenshot after executing zsh -xv. Then it should be fine to know where it is dying!

@yingzi17
Copy link
Author

yingzi17 commented Apr 12, 2024

my theme:

if [[ -z $ZSH_THEME_CUSTOM_PREFIX ]]; then
  ZSH_THEME_CUSTOM_PREFIX=">"
fi

PROMPT="%(?:%{$fg_bold[blue]%}$ZSH_THEME_CUSTOM_PREFIX:%{$fg_bold[red]%}$ZSH_THEME_CUSTOM_PREFIX)"
PROMPT+=' %{$fg[blue]%}%~%{$fg[yellow]%} %* %{$reset_color%}%% '
# PROMPT+=' $(git_prompt_info)'

ZSH_THEME_GIT_PROMPT_PREFIX="%{$fg_bold[green]%}%{$fg[magenta]%}"
ZSH_THEME_GIT_PROMPT_SUFFIX="%{$reset_color%} "
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[green]%} %{$fg[yellow]%}✗"
ZSH_THEME_GIT_PROMPT_CLEAN="%{$fg[green]%} $"

when i add this line "PROMPT+=' $(git_prompt_info)'" , it happens

@FishGoddess
Copy link

FishGoddess commented Apr 15, 2024

+1

I have reproduce the same issue:

# It's ok
$ git checkout b43b84abc77850a3734c127c38afdd7cf7739dc6

# Error, a core file will be generated in directory
$ git checkout ec1afe9dd683c36e6384db25fc1e95acbb0cbc7a

ec1afe9 commit:
image

@carlosala
Copy link
Member

I'm still not able to do so. Not sure what's missing. Could you send a screenshot after executing zsh -xv. Then it should be fine to know where it is dying!

Could anyone send this?

@AHzZ123
Copy link

AHzZ123 commented Apr 15, 2024

I'm still not able to do so. Not sure what's missing. Could you send a screenshot after executing zsh -xv. Then it should be fine to know where it is dying!

Could anyone send this?

The branch I am currently on is 31f2025, and enclosed is a screenshot taken prior to the termination of zsh.

image

@mcornella
Copy link
Member

Hi folks, thanks for all the reports and logs and such. Unfortunately we are unable to reproduce the issue (i.e. get it to core-dump). We have tested using CentOS 7 containers, as well as with a VM. However, based on #12331 (comment) we see that the segfault happens at the get_widget function.

Checking the blame for zsh, we found that a segfault was fixed on zsh 5.0.6 (commit and related zsh-workers thread). We were able to see that 5.0.6 was the first version to also not be affected by the stale branch info reported.

We therefore believe that 5.0.6 will not have the issue. I have also a hunch that get_widget will not be called if we replace zle reset-prompt with zle .reset-prompt, and as such I have raised #12358, which you can test by running omz pr test 12358. Please test it out and let us know whether this bypasses the crash, or otherwise it stays the same.

If we are unable to find the root cause, and as we can't successfully reproduce it, we will then disable the feature for zsh < 5.0.6, and just recommend that people upgrade (we know this is sometimes not a possibility, therefore we'll just turn off the async feature by default).

@MxDany
Copy link

MxDany commented Apr 17, 2024

  • coredup
gdb core.52857 
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.tl2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
[New LWP 52857]
Reading symbols from /usr/bin/zsh...Reading symbols from /usr/lib/debug/usr/bin/zsh.debug...done.
done.
Missing separate debuginfo for 
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/bf/5e00af64f7662d70e38e3383923fdbfe1b00a4
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/zsh -i'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fae42638eaa in get_widget (pm=0x13ea2c0) at zle_params.c:366
366         return bindk->nam;
Missing separate debuginfos, use: debuginfo-install ncurses-libs-5.9-14.20130511.el7_4.x86_64
(gdb) bt
#0  0x00007fae42638eaa in get_widget (pm=0x13ea2c0) at zle_params.c:366
#1  0x0000000000461556 in getstrvalue (v=v@entry=0x7ffc63babb10) at params.c:1999
#2  0x0000000000481f93 in paramsubst (pf_flags=<optimized out>, qt=<optimized out>, str=0x7ffc63baba90, n=<optimized out>, l=<optimized out>) at subst.c:2434
#3  stringsubst (list=list@entry=0x7ffc63babd70, node=<optimized out>, pf_flags=<optimized out>, pf_flags@entry=4, asssub=asssub@entry=0) at subst.c:236
#4  0x00000000004849e5 in prefork (list=list@entry=0x7ffc63babd70, flags=flags@entry=4) at subst.c:77
#5  0x00000000004851d1 in singsub (s=s@entry=0x7ffc63babdd8) at subst.c:397
#6  0x00000000004232e2 in evalcond (state=state@entry=0x7ffc63bada80, fromtest=fromtest@entry=0x0) at cond.c:180
#7  0x0000000000424726 in execcond (state=0x7ffc63bada80, do_exec=<optimized out>) at exec.c:4176
#8  0x0000000000425459 in execsimple (state=state@entry=0x7ffc63bada80) at exec.c:1119
#9  0x000000000042e4db in execlist (state=state@entry=0x7ffc63bada80, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0) at exec.c:1272
#10 0x00000000004515dc in execif (state=0x7ffc63bada80, do_exec=0) at loop.c:532
#11 0x000000000042ae74 in execcmd (state=state@entry=0x7ffc63bada80, input=input@entry=0, output=output@entry=0, how=<optimized out>, how@entry=2, last1=2) at exec.c:3242
#12 0x000000000042c3a6 in execpline2 (state=state@entry=0x7ffc63bada80, pcode=pcode@entry=4035, how=how@entry=2, input=0, output=0, last1=last1@entry=0) at exec.c:1712
#13 0x000000000042c7e3 in execpline (state=state@entry=0x7ffc63bada80, slcode=<optimized out>, how=how@entry=2, last1=0) at exec.c:1492
#14 0x000000000042e575 in execlist (state=state@entry=0x7ffc63bada80, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0) at exec.c:1264
#15 0x000000000042e862 in execode (p=p@entry=0x139c8f0, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0, context=context@entry=0x49461c "shfunc") at exec.c:1067
#16 0x0000000000426fe9 in runshfunc (prog=0x139c8f0, wrap=0x0, name=0x7fae44c2ed58 "_zsh_highlight") at exec.c:4905
#17 0x0000000000427a23 in doshfunc (shfunc=shfunc@entry=0x139bb10, doshargs=doshargs@entry=0x7fae44c2ecf8, noreturnval=noreturnval@entry=0) at exec.c:4794
#18 0x0000000000427e9f in execshfunc (shf=shf@entry=0x139bb10, args=args@entry=0x7fae44c2ecf8) at exec.c:4452
#19 0x000000000042bab7 in execshfunc (args=0x7fae44c2ecf8, shf=0x139bb10) at exec.c:4418
#20 execcmd (state=state@entry=0x7ffc63baf9a0, input=input@entry=0, output=output@entry=0, how=<optimized out>, how@entry=18, last1=<optimized out>) at exec.c:3291
#21 0x000000000042c3a6 in execpline2 (state=state@entry=0x7ffc63baf9a0, pcode=pcode@entry=259, how=how@entry=18, input=0, output=0, last1=last1@entry=0) at exec.c:1712
#22 0x000000000042c7e3 in execpline (state=state@entry=0x7ffc63baf9a0, slcode=<optimized out>, how=how@entry=18, last1=0) at exec.c:1492
#23 0x000000000042e575 in execlist (state=state@entry=0x7ffc63baf9a0, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0) at exec.c:1264
#24 0x000000000042e862 in execode (p=p@entry=0x139d460, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0, context=context@entry=0x49461c "shfunc") at exec.c:1067
#25 0x0000000000426fe9 in runshfunc (prog=0x139d460, wrap=0x0, name=0x7fae44c2dbe8 "_zsh_highlight_call_widget") at exec.c:4905
#26 0x0000000000427a23 in doshfunc (shfunc=shfunc@entry=0x139be00, doshargs=doshargs@entry=0x7fae44c2dae8, noreturnval=noreturnval@entry=0) at exec.c:4794
#27 0x0000000000427e9f in execshfunc (shf=shf@entry=0x139be00, args=args@entry=0x7fae44c2dae8) at exec.c:4452
#28 0x000000000042bab7 in execshfunc (args=0x7fae44c2dae8, shf=0x139be00) at exec.c:4418
#29 execcmd (state=state@entry=0x7ffc63bb18c0, input=input@entry=0, output=output@entry=0, how=<optimized out>, how@entry=18, last1=<optimized out>) at exec.c:3291
#30 0x000000000042c3a6 in execpline2 (state=state@entry=0x7ffc63bb18c0, pcode=pcode@entry=67, how=how@entry=18, input=0, output=0, last1=last1@entry=0) at exec.c:1712
#31 0x000000000042c7e3 in execpline (state=state@entry=0x7ffc63bb18c0, slcode=<optimized out>, how=how@entry=18, last1=0) at exec.c:1492
#32 0x000000000042e575 in execlist (state=state@entry=0x7ffc63bb18c0, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0) at exec.c:1264
#33 0x000000000042e862 in execode (p=p@entry=0x13bda00, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0, context=context@entry=0x49461c "shfunc") at exec.c:1067
#34 0x0000000000426fe9 in runshfunc (prog=0x13bda00, wrap=0x0, name=0x7fae44c2da50 "_zsh_highlight_widget_orig-s0.0000020000-r25992-reset-prompt") at exec.c:4905
#35 0x0000000000427a23 in doshfunc (shfunc=shfunc@entry=0x13bdaa0, doshargs=doshargs@entry=0x0, noreturnval=noreturnval@entry=1) at exec.c:4794
#36 0x00007fae42631fdc in execzlefunc (func=func@entry=0x7fae42857e98 <thingies+3480>, args=args@entry=0x7fae44c2d9c0, set_bindk=set_bindk@entry=0) at zle_main.c:1361
#37 0x00007fae4264063e in bin_zle_call (name=0x7fae44c2d9a0 "zle", args=0x7fae44c2d9c0, ops=<optimized out>, func=<optimized out>) at zle_thingy.c:711
#38 0x000000000041cac2 in execbuiltin (args=args@entry=0x7fae44c2d958, bn=bn@entry=0x7fae4285c520 <bintab+128>) at builtin.c:450
#39 0x000000000042bd4a in execcmd (state=state@entry=0x7ffc63bb6a20, input=input@entry=0, output=output@entry=0, how=<optimized out>, how@entry=2, last1=<optimized out>) at exec.c:3303
#40 0x000000000042c3a6 in execpline2 (state=state@entry=0x7ffc63bb6a20, pcode=pcode@entry=1219, how=how@entry=2, input=0, output=0, last1=last1@entry=0) at exec.c:1712
#41 0x000000000042c7e3 in execpline (state=state@entry=0x7ffc63bb6a20, slcode=<optimized out>, how=how@entry=2, last1=0) at exec.c:1492
#42 0x000000000042e575 in execlist (state=state@entry=0x7ffc63bb6a20, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0) at exec.c:1264
#43 0x0000000000451651 in execif (state=0x7ffc63bb6a20, do_exec=0) at loop.c:547
#44 0x000000000042ae74 in execcmd (state=state@entry=0x7ffc63bb6a20, input=input@entry=0, output=output@entry=0, how=<optimized out>, how@entry=2, last1=2) at exec.c:3242
#45 0x000000000042c3a6 in execpline2 (state=state@entry=0x7ffc63bb6a20, pcode=pcode@entry=1155, how=how@entry=2, input=0, output=0, last1=last1@entry=0) at exec.c:1712
#46 0x000000000042c7e3 in execpline (state=state@entry=0x7ffc63bb6a20, slcode=<optimized out>, how=how@entry=2, last1=0) at exec.c:1492
#47 0x000000000042e575 in execlist (state=state@entry=0x7ffc63bb6a20, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0) at exec.c:1264
#48 0x0000000000451651 in execif (state=0x7ffc63bb6a20, do_exec=0) at loop.c:547
#49 0x000000000042ae74 in execcmd (state=state@entry=0x7ffc63bb6a20, input=input@entry=0, output=output@entry=0, how=<optimized out>, how@entry=2, last1=2) at exec.c:3242
#50 0x000000000042c3a6 in execpline2 (state=state@entry=0x7ffc63bb6a20, pcode=pcode@entry=451, how=how@entry=2, input=0, output=0, last1=last1@entry=0) at exec.c:1712
#51 0x000000000042c7e3 in execpline (state=state@entry=0x7ffc63bb6a20, slcode=<optimized out>, how=how@entry=2, last1=0) at exec.c:1492
#52 0x000000000042e575 in execlist (state=state@entry=0x7ffc63bb6a20, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0) at exec.c:1264
#53 0x000000000042e862 in execode (p=p@entry=0x12cd3b0, dont_change_job=dont_change_job@entry=1, exiting=exiting@entry=0, context=context@entry=0x49461c "shfunc") at exec.c:1067
#54 0x0000000000426fe9 in runshfunc (prog=0x12cd3b0, wrap=0x0, name=0x7fae44c2d040 "_omz_async_callback") at exec.c:4905
#55 0x0000000000427a23 in doshfunc (shfunc=0x12caa10, doshargs=doshargs@entry=0x13e22e0, noreturnval=noreturnval@entry=1) at exec.c:4794
#56 0x0000000000489cb1 in callhookfunc (name=0x13a5780 "_omz_async_callback", lnklst=lnklst@entry=0x13e22e0, arrayp=arrayp@entry=0, retval=retval@entry=0x0) at utils.c:1265
#57 0x00007fae42631902 in raw_getbyte (cptr=0x7ffc63bb714f "", do_keytmout=0) at zle_main.c:755
#58 getbyte (do_keytmout=0, timeout=timeout@entry=0x0) at zle_main.c:844
#59 0x00007fae42630766 in getkeybuf (w=0) at zle_keymap.c:1484
#60 getkeymapcmd (km=0x12bc370, funcp=funcp@entry=0x7ffc63bb7308, strp=strp@entry=0x7ffc63bb7310) at zle_keymap.c:1428
#61 0x00007fae42630998 in getkeycmd () at zle_keymap.c:1520
#62 0x00007fae42632548 in zlecore () at zle_main.c:1039
#63 0x00007fae426331cd in zleread (lp=<optimized out>, rp=<optimized out>, flags=<optimized out>, context=<optimized out>) at zle_main.c:1228
#64 0x0000000000443872 in zleentry (cmd=cmd@entry=1) at init.c:1468
#65 0x00000000004452d6 in inputline () at input.c:288
#66 ingetc () at input.c:222
---Type <return> to continue, or q <return> to quit---
#67 0x000000000043da66 in ihgetc () at hist.c:306
#68 0x000000000044f29e in gettok () at lex.c:796
#69 zshlex () at lex.c:477
#70 0x000000000046d246 in parse_event (endtok=endtok@entry=37) at parse.c:481
#71 0x0000000000440ac6 in loop (toplevel=toplevel@entry=1, justonce=justonce@entry=0) at init.c:133
#72 0x000000000044426e in zsh_main (argc=<optimized out>, argv=<optimized out>) at init.c:1623
#73 0x00007fae438ed555 in __libc_start_main (main=0x40ee20 <main>, argc=2, argv=0x7ffc63bb7ab8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc63bb7aa8) at ../csu/libc-start.c:266
#74 0x000000000040ee4e in _start ()
(gdb) 
  • system version:
$ cat /etc/centos-release
CentOS Linux release 7.6 (Final)
  • zsh version
zsh --version
zsh 5.0.2 (x86_64-redhat-linux-gnu)
  • ~/.zshrc config
ZSH_THEME="random"
...
plugins=(git zsh-syntax-highlighting)
...
  • summary

The above is the environment in which I have problems, i use random theme, and I have installed zsh-syntax-highlighting plugin.
I tried, most themes will coredump, but some themes will not, for example, 'rkj','sunrise','oldgallois','michelebologna','gentoo', etc.

The following kinds of scenarios are ok:

  1. when no .git directory in current path
  2. when ZSH_THEME set to some specific theme, 'sunrise','oldgallois','michelebologna','gentoo', etc.
  3. when plugin zsh-syntax-highlighting is not installed
  4. when i change system to 'CentOS Linux release 8.6.2205 (Core)' with 'zsh 5.5.1 (x86_64-koji-linux-gnu)'
  5. i use 6dfa950 branch for a long time, it's very stable. and i start to test, gradually switched to the ec1afe9 branch, coredump begins to occur, So I think coredump is introduced by the ec1afe9 commit.

Hope this info helps!!!

@MxDany
Copy link

MxDany commented Apr 17, 2024

image As the test above concludes, I rollback the ec1afe9 commit and the problem disappeared, so if you guys have already determined that it's a historical bug in zsh, would it be possible to add a versioning judgment instead of forcing people to upgrade their zsh version

@mcornella
Copy link
Member

mcornella commented Apr 17, 2024

Program terminated with signal 11, Segmentation fault.
#0  0x00007fae42638eaa in get_widget (pm=0x13ea2c0) at zle_params.c:366
366         return bindk->nam;

That confirms our suspicions that 5.0.6 fixes the issue (in commit zsh-users/zsh@97115e0).

would it be possible to add a versioning judgment instead of forcing people to upgrade their zsh version

Yes, that was what I said in #12331 (comment).

The reason ec1afe9 keeps coming up in your tests of the bug introduction has already been explained: that's the one where we enable git async prompt by default. We already suggested the mitigation of disabling the setting, but I realise not in this specific thread: https://github.com/ohmyzsh/ohmyzsh#disable-async-git-prompt.

Now, as we can't reproduce the issue, we are trying to verify whether zle .reset-prompt bypasses the faulty code. For this, I created a PR which you can easily test with omz pr test 12358. Please, if we can get somebody to test whether this stops the crash, we will at least be able to have async prompt running for zsh < 5.0.6.

In the meantime, I have already pushed the code (1ed8d4b) that disables async prompt for 5.0.5 and older. You can get it with omz update, but it essentially does the same as the code in https://github.com/ohmyzsh/ohmyzsh#disable-async-git-prompt.

Please confirm whether #12358 fixes this. We need your test on this, otherwise you'll miss out on the feature.

@MxDany
Copy link

MxDany commented Apr 19, 2024

Please confirm whether #12358 fixes this. We need your test on this, otherwise you'll miss out on the feature.

I need test from vscode and random themes, and i don't know omz pr test 12358 can cover the test scenario or not. So I just test it directly using your branch test/async-crash-fix, I've tested it dozens of times and CORE hasn't happened again on my system. Great!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: core Issue or PR related to core parts of the project Bug Something isn't working
Projects
Status: Done
Development

No branches or pull requests

7 participants