endless loop when command completion after ./vi kicks in

• 报告人: (匿名)
• 属主: magicant
• 类型: Bugs
• 状态: 关闭
• 组件: shell-lineedit
• 里程碑: (无)
• 优先: 5 - Medium
• 严重性: 5 - Medium
• 处理结果: Fixed
• 文件: 无

Details 回复

after compiling https://github.com/aligrudi/neatvi, when i cd into the dir and type ./vi viTAB in the yash shell, yash goes into an endless loop. it seems to try to read input from fd3, and whenever i type something it reads that character and waits for the next, but never outputs anything. i straced it and figured it's trying to execute completion/vi followed by completion/ex. note that this happens on sabotage linux, where musl libc 1.1.24 is the main libc.

here's the last couple lines from strace output:

 fcntl(1, F_DUPFD_CLOEXEC, 100)          = 102
 fcntl(102, F_SETFD, FD_CLOEXEC)         = 0
 open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
 close(1)                                = 0
 dup2(3, 1)                              = 1
 close(3)                                = 0
 fcntl(2, F_DUPFD_CLOEXEC, 100)          = 103
 fcntl(103, F_SETFD, FD_CLOEXEC)         = 0
 close(2)                                = 0
 dup2(1, 2)                              = 2
 writev(1, [{"completion/ex", 13}, {"\n", 1}], 2) = 14
 close(2)                                = 0
 dup2(103, 2)                            = 2
 close(103)                              = 0
 close(1)                                = 0
 dup2(102, 1)                            = 1
 close(102)                              = 0
 rt_sigprocmask(SIG_SETMASK, [], [INT CHLD WINCH], 8) = 0
 ...
 pipe([3, 4])                            = 0
 rt_sigprocmask(SIG_BLOCK, ~[RTMIN 33 34], [INT CHLD WINCH], 8) = 0
 rt_sigprocmask(SIG_BLOCK, ~[], ~[KILL STOP RTMIN 33 34], 8) = 0
 fork()                                  = 5022
 rt_sigprocmask(SIG_SETMASK, ~[KILL STOP RTMIN 33 34], NULL, 8) = 0
 rt_sigprocmask(SIG_SETMASK, [INT CHLD WINCH], NULL, 8) = 0
 close(4)                                = 0
 read(3, "\33[m", 1024)                  = 3
 read(3, "\33[1;1H\33[K                                                                                \33[2;1H\33[K~                                         $
 read(3, "                                               \33[13;1H\33[K~                                                                               \33[14;$
 read(3, "             \33[24;1H\33[K                                                                                \33[1;1H\33[1;1H", 1024) = 115
 read(3, 

btw, congrats, thanks to yash this bug was found in musl libc: https://www.openwall.com/lists/musl/2020/11/19/1 (i actually found it when trying to rm file_with_utf_chars_in_ittab).

so i'm not sure whether this is a bug in yash 2.50 or musl libc, but this is beyond my expertise to debug it, as it involves arcane knowledge about yash internals to debug it.

任务单历史 (3/9 Histories)

2020-11-22 04:39 Updated by: None

• New Ticket "endless loop when command completion after ./vi kicks in" created

2020-11-22 12:31 Updated by: magicant

• Details Updated

评论 回复

Thank you for the bug report.

The completion script for vi executes vi --version to see if it is Vim or not, but this may have undesired effect if the command does not exit cleanly (especially if the command does not recognize the version option). I'll consider updating the script so that it checks the version in a more safe way.

2020-11-22 13:22 Updated by: None

评论 回复

thanks for your reply.

The completion script for vi executes vi --version

hmm, i suspected that would happen (after reading the completion script), therefore i checked strace log but didn't see any execve, strange... hmm maybe i should've used strace -f ?

2020-11-22 14:33 Updated by: magicant

评论 回复

(匿名) への返信

maybe i should've used strace -f ?

yes, execve should be observed on a child process.

2021-01-01 15:52 Updated by: magicant

评论 回复

I hope the issue is mitigated by r4163 but I'm still not sure if it works in all environments.

2021-02-08 15:39 Updated by: None

评论 回复

no, unfortunately the issue persists in 2.51.

2021-02-09 00:30 Updated by: magicant

评论 回复

r4163 is not included in 2.51. Could you try the latest commit from the repository?

2021-02-09 07:55 Updated by: None

评论 回复

oh oops. i applied https://github.com/magicant/yash/commit/988d0831968e32834e8aa79e7a5fdb7341cdb943.patch to yash 2.51 release tarball and it does indeed fix the issue. great job.

would you mind commenting on the SIGHUP issue i mentioned in #40964 ? thanks

2023-09-12 00:31 Updated by: magicant

• 状态 Update from 开启 to 关闭
• 处理结果 Update from 无 to Fixed