On 24 September 2016 at 22:31, Bart Schaefer wrote: > You're probably interested in getbyte() in zle_main.c, but you might > also attach with a debugger and put a breakpoint in zhandler so you > can get a stack trace of where the handler is being called [if it is]. > (Starting the debugger first and running zsh inside it won't work as > well because the debugger itself will trap the signals). It turned out that lldb stops at Ctrl-C even without b zhandler and this is what I've been receiving. The stack trace is at the end. But I've catched another thing. After Ctrl-C in .recursiveedit the timeouts at select() in raw_getbyte() stop occuring. Here is simple video that very well covers this. It shows debug prints stop appearing (attached 10-context lines diff). And Zconvey stops working, i.e. sched doesn't call its functions: https://asciinema.org/a/7s5dofinxlnn1i80ojunzybp7 ----------------- BT 10 / LLDB ---------------- (lldb) bt 10 * thread #1: tid = 0x1c441b, 0x00007fff897b107a libsystem_kernel.dylib`__select + 10, queue = 'com.apple.main-thread', stop reason = signal SIGINT * frame #0: 0x00007fff897b107a libsystem_kernel.dylib`__select + 10 frame #1: 0x00000001082b70e0 zle.so`raw_getbyte(do_keytmout=0, cptr="") + 640 at zle_main.c:615 frame #2: 0x00000001082b6abf zle.so`getbyte(do_keytmout=0, timeout=0x0000000000000000) + 319 at zle_main.c:893 frame #3: 0x00000001082b5798 zle.so`getkeybuf(w=0) + 24 at zle_keymap.c:1663 frame #4: 0x00000001082b54b6 zle.so`getkeymapcmd(km=0x00007fbe3201ce00, funcp=0x00007fff57c81c10, strp=0x00007fff57c81bf8) + 102 at zle_keymap.c:1581 frame #5: 0x00000001082b5903 zle.so`getkeycmd + 35 at zle_keymap.c:1692 frame #6: 0x00000001082b8430 zle.so`zlecore + 320 at zle_main.c:1136 frame #7: 0x00000001082b951b zle.so`recursiveedit(args=0x00000001083d3a00) + 27 at zle_main.c:1903 frame #8: 0x00000001082b7ea2 zle.so`execzlefunc(func=0x00000001082ea408, args=0x00000001083d3a00, set_bindk=1) + 770 at zle_main.c:1455