Because RTC is an integral debugging feature, all debugging functions such as setting breakpoints and examining variables can be used with RTC, except the Collector.
The following list briefly describes the capabilities of RTC:
Detects memory access errors
Detects memory leaks
Collects data on memory use
Works with all languages
Works on code that you do not have the source for, such as system libraries
Works with multithreaded code
Requires no recompiling, relinking, or makefile changes
Compiling with the -g flag provides source line number correlation in the RTC error messages. RTC can also check programs compiled with the optimization -O flag. There are some special considerations with programs not compiled with the -g option.
For more detailed information on any aspect of RTC, see the online help.
One way to avoid seeing a large number of errors at once is to use RTC earlier in the development cycle, as you are developing the individual modules that make up your program. Write a unit test to drive each module and use RTC incrementally to check one module at a time. That way, you deal with a smaller number of errors at a time. When you integrate all of the modules into the full program, you are likely to encounter few new errors. When you reduce the number of errors to zero, you need to run RTC again only when you make changes to a module.
To use RTC, you must fulfill the following requirements.
Programs compiled using a Sun compiler
Dynamic linking with libc
Use of the standard libc malloc/free/realloc functions or allocators based on those functions. RTC does provide an API to handle other allocators; see "Using Fix and Continue With RTC".
Programs that are not fully stripped; programs stripped with strip -x are acceptable.
RTC does not handle program text areas and data areas larger than 8 megabytes.
A possible solution is to insert special files in the executable image to handle program text areas and data areas larger than 8 megabytes.