How do I use PURIFY with OPNET to debug memory problems on UNIX?

How do I use PURIFY with OPNET to debug memory problems on UNIX?

The following instructions are for UNIX platforms. For Windows, please see FAQ #517: How can I use Purify with OPNET under Windows?1. Follow the instructions in your PURIFY users guide to set up your account to run PURIFY. Based on memory management in OPNET, you may want to use -pointer_offset=8 .2. Compile all process models with the debug compilation flag by modifyingthe comp_flags and comp_flags_cpp environment attributes in your env_db file. The value to use is typically -g with the leading space. For OPNET release 10.0 or later, no need to modify any environment attribute.3. Modify your binding script (bind_gcc or bind_unix)which is set by the bind_static_prog environment attributein your env_db file. These scripts are located in <opnet_directory>/sys/unix/bin. You can easily find this pathname by entering which bind_unix in your shell.The last line in this script should be a call to your compiler as in:$cc <arguments>At the beginning of this line add the word purify followed by a space:purify $cc <arguments>4. Create a static simulation using the op_mksim utility. WARNINGS:1. Note that because purify provides feedback while instrumenting, op_mksim may report a linking failure Attempt to bind simulation failed... even if everything went fine. (This is because the binder may output messages indicating a success, while OPNET interprets any output as problematic.)2. Purify may cause too many files to be opened at the same time. If you see errors when running a purified program which states unable to open a file, you may have to increase the number of files a process can open. On Solaris:Check the current limit on your shell using 'ulimit'% ulimit -nTo raise the limit in a given shell, use 'limit'% limit descriptors 2003. When purify instruments an executable, it also instruments **ALL** the shared libraries that the executable uses, including the system libraries. The resulting instrumented libraries are usually stored in a cache directory (or rather a cache tree) that mimics the directory hierarchy where the libraries were found (e.g., the instrumented libc.so is in usr/lib). By default, purify uses a directory named 'pcache' in its installation area, but this would mean that the libraries for several instrumented programs end up in the same place. This is fine as long as the versions of all the libraries are identical, but you may encounter problems if there are different versions of the same libraries. You can avoid some of those problems by creating a cache directory on your local machine (e.g., in /usr/local/purify/<dir_name>) and, add the following to PURIFYOPTIONS or PUREOPTIONS: -cache_dir=/usr/local/purify/<dir_name>4. See also OPNET FAQ: Why should I run OPNET programs - including simulations - with the 'mem_optimize' environment attribute set to FALSE when running under BoundsChecker, Purify, etc. 5. If you use a static simulation created using op_mksim as described above, read the FAQ Why do I get different results when I run a simulation from the command line vs. running the same simulation from the OPNET GUI?. 6. NOTE: this is a workaround for the Opnet Software Problem # 18888 which only affects Modeler versions 7.0 and 8.0 PL7 and earlier.Add -lXext into bind_shobj_flags & bind_static_flags preferences.

DES Kernel->Other