`quit` always terminates the debugger and not just the subshell of the debugged program

[jansorg]

test-frame of make check is failing on my system (and also on CI, I think). I tried to debug this and was able to create a simple script to reproduce. I'm not entirely sure that it's the main cause, but it seems like a bug to me.

When the debugged script is stopped inside a subshell, then quit does not just quit the subshell, but the complete zshdb debugger. bashdb on the same script is correctly terminating only the subshell.

File used for testing:

(
        echo in subshell
)

zshd commands used for testing:

# ./zshdb -L . /home/jansorg/test-subshell.sh
quit

In the log below please note that "zshdb: That's all, folks..." is printed twice.

I've tracked this down to this line in processor.sh on my system. vared is terminating with status code 1, which then terminates the loop to run commands. Disabling vared (by using the code of the else branch) fixed the bug for me. My suspicion is that a hook/trap handler is causing this, but I wasn't able to find out.

$ cat /home/jansorg/test-subshell.sh 
(
        echo in subshell
)

echo at top-level

$ ./zshdb -L . /home/jansorg/test-subshell.sh 
zsh debugger, zshdb, release 1.1.4dev

Copyright 2008-2011, 2014, 2016-2020, 2023 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.

(/home/jansorg/test-subshell.sh:1):
(
        echo in subshell
)
zshdb<0> quit
zshdb: That's all, folks...
Debugged program terminated normally. Use q to quit or R to restart.
zshdb<1> 

zshdb: That's all, folks...

[rocky]

Thanks for the report. I will try to look at this over the weekend when I have time.

[rocky]

Thank you for isolating this problem. I can confirm what you report.

To sum up what you write, something is causing

vared -e -h -p "$_Dbg_prompt" -t "$_Dbg_tty" line 

to give a 1 return code. I get the same result if options -e -h are removed.

Looking at https://zsh.sourceforge.io/Doc/Release/Zsh-Line-Editor.html#Zle-Builtins and the vared section, I don't see what causes a nonzero exit without giving a message.

I agree this is probably in the _Dbg_cleanup() function, but I haven't been able yet to determine exactly what it is.

Here is a sample script that succeeds.

typeset line=''
setopt extendedhistory extendedglob shwordsplit ksharrays histignoredups zle rematchpcre bashrematch localtraps
vared -p "type something: " -t $(tty) line
echo you typed: $line
line=""
unsetopt extendedhistory extendedglob shwordsplit ksharrays histignoredups zle rematchpcre bashrematch localtraps
set -569Xf
vared -p "type something else: " -t $(tty) line
echo you also typed: $line

If we can get the second vared to fail, then it will become clearer as to whether this is a zshdb or a zsh feature and how to work around it. If we feel it is a zsh bug, or something that needs clarification, I can go to the zsh community and seek guidance.

I will look more later. This weekend I may be crimped for time though.

[rocky]

I looked at this more and things are a mess. The problem has nothing to do with _Dbg_cleanup() but rather that the quit command issues an exit. I guess exit cleanup in zsh is now more thorough and does not allow vared from getting called.

So instead of issuing an exit, the quit command can issue a return. Just doing that does not leave the debugger command loop when it is stopped before running a particular zsh command. And that process debugger command loop is infinite. That loop can be made conditional though. But there is yet another infinite loop a in the top-level zshdb program. That too can be made conditional as well.

I haven't however been able to get all of this working properly though.

[rocky]

Tests have been corrected now. And changes have now been merged to master. See if this addresses the problems. If so, close the ticket. If not, the elaborate.

Sorry for the delay.

[jansorg]

Thank you! This is working well for me now...