When you stop your program to inspect data, objects might not be in a fully consistent state. This may happen in a number of circumstances, such as:
*Stopping in a the middle of a constructor or destructor.
*Displaying an object in scope, but before its constructor has been called.
*Viewing a dangling pointer to an object, that is, a pointer to an object in memory that has been released by the program. This may be stack memory, but also heap memory. (If the target is running with memory debugging enabled, then TotalView does check that the object to be displayed does not lie in a deallocated region. If it does, then it does not call your TV_ttf_display_type, and will display the data in their raw form You should not, however, rely on this check.)
In the absence of C++View, this is not a problem, as displaying the data is just a matter of reading memory. However, with C++View, displaying data now involves executing functions in the target code. Your functions should be careful to check that the object to be displayed is in a consistent state. If you can't establish that with certainty, then it should not attempt to format the data, and instead it should return TV_ttf_format_failed.
Otherwise, your target program may crash when you attempt to display an object at an inappropriate time. As with any function call made from TotalView (expression list, evaluation window, etc.), TotalView recovers from this in a limited manner by posting an error message and restoring the stack to its original state. However, the target code may be left in an inconsistent or corrupted state, and further progress may not be possible or useful.
You may not place a breakpoint in a TV_ttf_display_type function. If you do, the callback will be aborted similarly, and TotalView will display an error.