Debugging Tcl Callback Code

The first step in debugging a callback is to make sure that the function can works when it is not used in a type transformation callback; that is, if the function works when it is not used within a type mapping, it should work within one. Many procedures do not need to be tested within TotalView and can instead be tested directly by using a Tcl interpreter such as tclsh. In this environment, you can use standard Tcl debugging tools.

If one of your procedures throws a Tcl error inside a TotalView callback, TotalView prints a Tcl stack backtrace. For example:

CLI callback 'dfocus {1.1} {vector_address
    {class vector<int,allocator<int> >} 0xbffff9dc {0 } }' failed
    can't read "foo": no such variable while executing
    "set type_sizes $foo"
        (procedure "vector_address" line 6)
        invoked from within
    "vector_address {class vector<int,allocator<int> >}
    0xbffff9dc {0 } " invoked from within
    "dfocus {1.1} {vector_address {class
    vector<int,allocator<int> >}
    0xbffff9dc {0 } }"

If neither of these techniques helps, you will need to print values from your Tcl code as it executes so that you can see what is happening. You might want to use a debugging procedure such as:

proc my_puts {{string ""}} {
    global gMy_Debug
    
    if {$gMy_Debug} {
        puts $string
    }
}

The my_puts function will only print a message if the gMy_Debug global variable is set to true. This lets you enable and disable printing information by changing gMy_Debug's value.