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

["Rocky Bernstein" <rocky.bernstein@xxxxxxxxx>]

On Mon, Sep 29, 2008 at 7:25 AM, Peter Stephenson <pws@xxxxxxx> wrote:
> "Rocky Bernstein" wrote:
>> Thanks. This addresses one of the problem seen. There are still the
>> others -- output disappearing and weird line numbers shown further up
>> in the trace. But we will take these one at a time.
>
> Please could you send a simple example of a remaining incorrect line
> number.  I would expect it would be reproducible without the debugger.

Sorry. Here's a trace from the reduced debugger. I've added comments as before.

./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

(./zshdb2.sh:34):               # Comes from debugger via above save
. ./testing.sh
./zshdb2.sh:39 ./zshdb2.sh:34   # lib/frame.sh output again
zshdb<1> p ${funcfiletrace[@]}
./command/eval.sh:38 ./command/eval.sh:56 ./lib/processor.sh:100
./lib/processor.sh:49 ./zshdb2.sh:39 ./zshdb2.sh:34

# Above should be:  ./command/eval.sh:11 ./command/eval.sh:27
./lib/processor.sh:96 ./lib/processor.sh:44 ./lib/hook:13
./lib/hook.sh:6 ./zshdb2.sh:39 ./zshdb2.sh:34

Note that the difference in the two ./lib/processor.sh call lines is
52 in one case and 51 in another.

It gets even screwier after this, Just install that reduced debugger
and keep stepping and printing funcfiletrace. But again, perhaps it is
best to take things one step at a time.

>
>> How do you feel about noting the subshell level in one of the
>> traceback stacks and allowing an optional parameter to set $LINENO in
>> those cases where it is reset to 1.
>
> I'm not entirely sure what you're referring to, please could you give an
> example of what behaviour you'd like.

Ok. But I'm responding to your assertion that in some cases the line
number is reset to 1 in places where you can figure that out via
funcfiletrace. I see that eval doesn't seem to be such a case.

Suppose eval line numbers were reset but it is shown as a call in the
stack traces as it is in Python and Ruby. This code then

# This is line 5
eval "x=1;
y=$LINENO"

would set y to 2 since that's the second line in the eval. Since eval
is a POSIX "special" builtin, let's say there is an eval2 which allows
optional file and line number parameters

eval "x=1;
y=$LINENO" 10 foo.c

Then y would be set to 10. And *stack* routines where we can see
filename, it would be "foo.c"

>
>> (Is there a corresponding variable for the filename?
>
> LINENO itself doesn't necessarily relate to a file, but for now you can
> use ${(%):-%x} and ${(%):-%I} for the filename and line number in the
> shell code which is probably what you need.  I'll add variables for
> these later if they turn out to be useful (probably ZSH_SOURCE_FILE and
> ZSH_SOURCE_LINE).

Ok - Thanks. Will see how this works out. I'm not a fan of only having
% notation which looks like line noise and as you yourself had said in
the past %x is a bit non-intuitive.

>
>> I note that in
>> x="
>> $LINENO"
>>
>> LINENO has the x's line number rather than the one it's on. No doubt
>> this is an artifact of xtrace wanting to show for tracing purposes x's
>> line. However probably more correct would be to keep that but have
>> $LINENO be the line that it itself is on.
>
> I think we'd have to track the line number in subst.c:stringsubst().
> That may or may not be simple, I'll have to try it.

I think it will help. Thanks.