Description of problem: Sometimes hitting tab to complete a filename will cause this to happen. Not always, not on any specific disk or with any specific files, and I haven't found a way to replicate this yet. 1) Open zsh 2) Have menu tab completion enabled (setopt auto_menu) 3) Type part of a filename and press <Tab> 4) Repeat until this happens I can publish the current completion system that I'm using if that helps. Version-Release number of selected component: zsh-5.0.6-1.fc20 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: zsh crash_function: execute executable: /usr/bin/zsh kernel: 3.16.4-200.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 execute at exec.c:609 #1 execcmd at exec.c:3342 #2 execpline2 at exec.c:1691 #3 execpline at exec.c:1478 #4 execlist at exec.c:1261 #5 execode at exec.c:1070 #6 getoutput at exec.c:3764 #7 stringsubst at subst.c:293 #8 prefork at subst.c:77 #9 multsub at subst.c:493
Created attachment 951632 [details] File: backtrace
Created attachment 951633 [details] File: cgroup
Created attachment 951634 [details] File: core_backtrace
Created attachment 951635 [details] File: dso_list
Created attachment 951636 [details] File: environ
Created attachment 951637 [details] File: exploitable
Created attachment 951638 [details] File: limits
Created attachment 951639 [details] File: maps
Created attachment 951640 [details] File: open_fds
Created attachment 951641 [details] File: proc_pid_status
Created attachment 951642 [details] File: var_log_messages
Could you please update to zsh-5.0.7-1.fc20 and try to reproduce it? https://admin.fedoraproject.org/updates/FEDORA-2014-12596/zsh-5.0.7-1.fc20 I see there were some changes in exec.c but not sure if related to this bug.
No, it still happens with 5.0.7-2.fc21. (Pardon the long reply)
Thanks for the reply! Do you define a command_not_found_handler() function in your configuration? If yes, could you please attach its code?
Pretty sure that has something to do with it. I brought over my configurations from Arch, and there was a pkgfile command in there. Replaced that with the proper dnf command and it seems everything is fixed. I'll keep testing and see what happens in the next few days. I still don't have a way to reliably reproduce this, sadly.
Thanks for the confirmation! The cause of the crash is an infinite (indirect) recursion inside a single process of zsh. It terminates at call depth 2047 when the stack frame of execute() exceeds the memory area reserved for stack. The trace goes through the commandnotfound() function, which is responsible for handling the command_not_found_handler() fallback. So far I was not able to trigger the crash, will give it one more try using the backtrace attached to this bug.
William, you forgot to attach the code of your command_not_found_handler(). I tried to use this one to no avail: https://github.com/falconindy/pkgfile/blob/master/extra/command-not-found.zsh The backtrace goes through comp_wrapper(), which suggests there must be some additional zsh modules loaded if I read the code correctly. There is just too man unknown conditions for me to trigger the bug locally. I am closing the bug now. Feel free to reopen it once you have a self-contained reproducer...
Ah, sorry. And that is the handler function I had, too. I'm fine closing this for now. I haven't seen it occur again since I set up the dnf version of the handler.