Re: Help me track down a tough bug? (probably funcfiletrace, subshells and possibly I/O redirection)

["Rocky Bernstein" <rocky.bernstein@gmail.com>]

On Mon, Sep 29, 2008 at 5:42 PM, Peter Stephenson
<p.w.stephenson@ntlworld.com> wrote:
> On Mon, 29 Sep 2008 15:25:28 +0100
> Peter Stephenson <pws@csr.com> wrote:
>> "Rocky Bernstein" wrote:
>> > ./zshdb2.sh
>> > ./zshdb2.sh:39 ./zshdb2.sh:34   # Debug output in lib/frame.sh
>> >
>> > # Above should be: ./lib/hook.sh:5 ./zshdb2.sh:34
>> > # note: 34+5=39
>>
>> Ah, I see, so this should be fairly obvious once I track back and see
>> what the code referred to is... I'll try and get round to this this
>> evening.
>
> Wasn't so easy, since there was quite a lot of irrelevant stuff to
> strip.

If you started with zshdb-0.01bug, if it is of any consolation, I'd
been stripping stuff out all weekend, well as trying to create simple
test cases. If you started with the git source well, yes, that's quite
large.

>  It turns out the problem is handling of functions inside traps.
> These inherit the behaviour of the parent (eval-style, i.e. not
> TRAP...() { ... } ) trap that the line number isn't updated, it's kept
> as that in the line that caused the trap.  This causes oddities like
> this, so I think it wants turning off so that the functions called from
> the trap act normally.  This seems to accord with the principle of least
> surprise, too.

Works much better. Thanks! (Really, I had been living with messed up
line numbers in debugger code for a while. You get them in xtrace
output as well. )

> That seems to fix the problem, but I'm sure I'll be
> hearing if it doesn't.

You are correct. It's really the next set of problems that I was more
concerned about since this is something users of a debugger see rather
than me or folks who happen to use trap DEBUG. Since you asked for
specific line numbers, posted them. And I think in order to get to the
next part I guess we have to remove this problem first since it is
what is the most glaring part.

So if you have zshdb-0.01bug around keep stepping:

$ ./zshdb2.sh

./zshdb2.sh:7 ./zshdb2.sh:34  # Much better. Thanks!
(./zshdb2.sh:34):
. ./testing.sh
./zshdb2.sh:9 ./zshdb2.sh:34  # Also correct!
zshdb<1> p ${funcfiletrace[@]}

./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96
./lib/processor.sh:44 ./zshdb2.sh:9 ./zshdb2.sh:34
# Above is still good! Now watch what happens next
./zshdb2.sh:9 ./zshdb2.sh:34
zshdb<2> s

./zshdb2.sh:7 ./testing.sh:3 ./zshdb2.sh:34 # Correct
(./testing.sh:3):
( x=$(print 5; print 6) )
./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34 # Correct
zshdb<3> p ${funcfiletrace[@]}

./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96
./lib/processor.sh:44 ./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34
./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96
./lib/processor.sh:44 ./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34
./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34
# Were did that double set of lines come from?
# Try again..
zshdb<4> s

./zshdb2.sh:7 ./testing.sh:4 ./zshdb2.sh:34 # Correct
(./testing.sh:4):
x=$(print 5; print 6)
./zshdb2.sh:9 ./testing.sh:4 ./zshdb2.sh:34 # Correct
zshdb<(5)> p ${funcfiletrace[@]}

./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96
./lib/processor.sh:44 ./zshdb2.sh:9 ./testing.sh:4 ./zshdb2.sh:34
./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96
./lib/processor.sh:44 ./zshdb2.sh:9 ./testing.sh:4 ./zshdb2.sh:34
./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96
./lib/processor.sh:44 ./zshdb2.sh:9 ./testing.sh:4 ./zshdb2.sh:34
# Now 3 copies
./zshdb2.sh:9 ./testing.sh:4 ./zshdb2.sh:34
zshdb<(6)> ...

And the printing of funcfiletrace masks another problem which I think
is more serious. It's possible this has nothing to do with
funcfiletrace but might be related to the repeating lines above. What
is happing is that instead of duplicate lines, output disappears. The
missing output occurs before "zshdb<((4))>" below.

#
$ ./zshdb2.sh
./zshdb2.sh:7 ./zshdb2.sh:34
(./zshdb2.sh:34):
. ./testing.sh
./zshdb2.sh:9 ./zshdb2.sh:34
zshdb<1> s

./zshdb2.sh:7 ./testing.sh:3 ./zshdb2.sh:34
(./testing.sh:3):
( x=$(print 5; print 6) )
./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34
zshdb<2> s

./zshdb2.sh:7 ./testing.sh:4 ./zshdb2.sh:34
(./testing.sh:4):
x=$(print 5; print 6)
./zshdb2.sh:9 ./testing.sh:4 ./zshdb2.sh:34
zshdb<(3)> s

zshdb<((4))> s

zshdb<((5))>

> I suspect sources inside eval-style traps behave
> similarly and ought to be fixed, which could be done with sourcelevel,
> but sufficient unto the day etc.  (The tests could also be done by
> pushing a special FS_TRAP type onto funcstack, but that has obvious
> visible consequences.  funcstack is a relative latecomer and could have
> been used for also sorts of things we now do other ways.)
>
> Responses avoiding "it should have been done completely differently from
> the start", "it would be nice to have an option to do it completely
> differently" and "other languages do this much better" preferred.

I'm not complaining! Beggar's can't be choosers.

Personally, I think it interesting and useful to know about how other
languages which have encountered the same or similar problems have
solved them. But if this is irksome, I'll not mention in the future.

Thanks for the speedy fixes on these issues.