how to debug "no such variable"
canvas_remix
We have a huge Tcl application and every now and then, some
variable is accessed which is undefined and we get this error :
"Cann't read <so-and-so>; no such variable"
How can we debug the source of this error efficiently without looking
through all the
source files for that variables?
I mean how can we generate some kind of stack trace for such a
variable ?
suchenwi
A non-existing variable cannot be stack-traced. But when the error you
mention occurs, the global variable errorInfo contains a stack trace
for the place where the error occured, with proc names and line
numbers. Example:
proc f x {expr {[g $x]*2}}
proc g x {expr {[h $x]+1}}
proc h x {return $foo}
puts [f bar]
reports:
can't read "foo": no such variable
while executing
"return $foo"
(procedure "h" line 1)
invoked from within
"h $x"
(procedure "g" line 1)
invoked from within
"g $x"
(procedure "f" line 1)
invoked from within
"f bar"
invoked from within
"puts [f bar]"
(file "/Tcl/t.tcl" line 9)
canvas_remix
written, I can print the stack trace.
right ?
Robert Heller
Is this a popup error box? If it is the standard Tcl/tk error popup,
you should be able to click on the 'show details' and get a stack trace.
>
>
--
Robert Heller -- Get the Deepwoods Software FireFox Toolbar!
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Larry W. Virden
>
> Is this a popup error box? If it is the standard Tcl/tk error popup,
> you should be able to click on the 'show details' and get a stack trace.
I suspect it is a tcl error going out to stderr.
Bruce Hartweg
no, if the variable doesn't exist, there are no writes
and there is nothing to trace. the stack trace exists
at the point in code that throws the "no such variable" error.
Bruce
Robert Heller
Which should include a stack trace...
NewbieDrew
I faced a similar problem some time ago. For starters, grep is your
friend for finding places that look like they are setting a value into
the variable in question. I wasted a great deal of time looking for
ways that the variable I was referencing could be in a different scope
than the variable that was getting the value that wasn't there when I
needed it. I eventually had a test case where the global variable
had a value on one pass through the function with the problem, but on
a later visit, the variable had become uninitialized. TCL has a
statement that can delete a variable, so a variable can go from having
a value to being without one. More confusing still, the name of the
variable to delete can be a glob expression, so grepping for the
specific variable name that has lost its value didn't turn up the
delete statement that was making the value go away. Grepping for
all the delete statements and contemplating them finally provided the
enlightenment that I sought. A routine had been added to the program
that was attempting to reset it so another "run" could be made without
exiting and restarting the program. That was where the bug was
lurking.
I pass along this tale in hopes that it helps you with your problem.
On my way to resolving that problem, I pushed the code through a
pretty-printer program that gave me paginated listings and an index to
the pages. The first try, the humongous program crashed the pretty
printer. Fortunately, the fellow who supported the pretty printer
program was happy to have a new test case. Turned out there were
files with unbalanced brackets and that flumoxed his parser. Finding
and fixing those certainly helped things along in my effort to get the
bugs out of the program I'd inherited. The experience certainly
drove home that debugging TCL is different than debugging C. Unless
you have test cases that specifically drive execution into the various
corners, there can be glaring syntax errors that the "compiler" didn't
flag when it ingested the files. (That was likely TCL 8.3.something
and maybe has changed in more recent editions? I've been away from
the language for a while now, so I can't really say what has changed
in recent years)
R.Drew Davis
(retired from Bell Labs)
Cameron Laird
.
.
Standard Tcl doesn't build in [delete].
I'm not accusing you of insincerity. I do suspect,
though, that there might be a ... different description
of your situation that you, and others, might agree is
more illuminating.
I suspect it was a Tcl/Tk application in which you were
involved, and ... well, it's a shame that your predecessors
left it in the condition you found.
NewbieDrew
> In article <1191603347.386439.32...@r29g2000hsg.googlegroups.com>,
That's news to me. But then all the TCL I was incolved with was
TCL/TK.
> I'm not accusing you of insincerity. I do suspect,
> though, that there might be a ... different description
> of your situation that you, and others, might agree is
> more illuminating.
I'm still puzzled as to how/why the code with unbalanced brackets
passed through the compiler without complaint. It sickened the
simple-minded parser in the pretty-printer. Why didn't it provoke
at least some warnings from the compiler?
> I suspect it was a Tcl/Tk application in which you were
> involved, and ... well, it's a shame that your predecessors
> left it in the condition you found.
I wasn't dumping on TCL. The same folks bestowed upon me some
horrendous C that I fixed by replacing that routine with a TCL routine
that did the same thing, but without the coding mistakes that the
lightest of test data could bring out in the original implementation.
And I'm willing to concede that they also wrote some of the worst
looking Java code that I'd ever want to see. Reminded me of the old
adage that there's no programming language that keeps you writing your
programs in Fortran.
To be fair to the people, they were mathematicians, not software
folks. They quickly generated programs that let them demonstrate
the mathematical concepts they were talking about. The problems
came when management mistook the demos for something deployable. If
they were paid on a lines of code/day basis, they'd make a good income
as they could really shovel out lines of code that gave the appearance
of working, at least for the case they showed in the demo. Me?
I'd rather waste some time on doing a design first. And testing the
implementation piece by piece so there'd be less chance of surprises
when the program is exposed to some new case.
Drew