The CaseVision/WorkShop tools from SGI offer a wealth of power to the ARX developer. The tips presented here are aimed toward the use of the CV tools although they should apply to the standard command-line 'dbx' debugger as well.

Debugging ARX:

First, to debug ARX applications, a few concepts need to be understood.

1. The ARX application (e.g. foo.arx) is implemented as an IRIX dynamic shared object (DSO). As such, it lacks a main() function and can't be run (or debugged) by itself. This means you need to debug AutoCAD itself:
   1. You can either start AutoCAD from within the debugger
      1. Use the shell script cvd_acad or dbx_acad.
   2. Attach the debugger to a running AutoCAD session:
      1. cvd -P acad
2. AutoCAD itself is a stripped executable, meaning it has no symbol table for the debugger to use. However, by clever planning, the other ARX applications shipped with AutoCAD, do include limited symbol tables.
   1. This is important in that all ARX applications contain the acrxEntryPoint() function.
   2. Therefore, if you load one known good ARX application, you can now set a breakpoint at acrxEntryPoint() in this application, then load your own application, the debugger will automatically set a breakpoint at its acrxEntryPoint() function as well.
      1. Set breakpoints with the CVD command:
         1. cvd > stop in acrxEntryPoint
3. At this point you are at the beginning of the first call AutoCAD makes to acrxEntryPoint(). Usually a second call will happen before your application can process commands. You can now set breakpoints in your code simply by clicking the mouse to the left of the line of code you wish to break at.
   1. If your debugger Main View is not showing your source files, use the Source->Open menu to load the file associated with the function you are stopped in. After this, the debugger should be able to map the file names in your application to the proper source locations.
   2. You most likely will see a cvd warning that the source file is newer than the executable.
      1. This really means that your source has a later modification date than the AutoCAD executable.
      2. Since your ARX application is dynamically linked into AutoCAD, the debugger does not see it at a separate process.

Error Messages:

If your ARX application causes a run-time error inside AutoCAD, you'll probably get an error dialog with a message like: "AutoCAD can't continue...". Then AutoCAD will exit and you may see one of the following kinds of messages in your shell window:

• Segmentation Violation (SEGV):
  • This error means your application attempted a memory reference outside of its address space (segment) and the operating system trapped the violation.
  • This error is often caused by NULL or uninitialized pointers (unlike the PC environment where accesses to 0x0 is legal, this is a fatal error in IRIX).
• Bus Error:
  • Bus errors indicate a memory reference to unaligned data, usually floating point.
  • In the MIPS architecture, floating point data must be on quad-word boundaries for proper access. Normally the compiler will pad data structures to ensure this but if you are dealing with arbitrary file or stream data, you may encounter unaligned data.
  • A workaround for unaligned floating point data is to copy it byte by byte from an unaligned location to an aligned one. Then reference the aligned location as floating point.
  • Most likely if you have unaligned file data, you may also need to address byte order issues at the same time, so both these tasks can be accomplished at the same time.

Since AutoCAD has internal signal handlers, you'll most likely never see a 'core' dump from AutoCAD. Rather, you'll need to run AutoCAD in the debugger, then let the debugger trap the signal and tell you where in your application the error occurred.

• This is the default behavior in the debugger, so you don't really need to do anything special to make this happen.

Finding Memory Allocation Errors:

The WorkShop package includes a memory allocation library that offers run-time debugging information. Normally, you would link the debug library into your application, but since ARX applications are themselves linked into AutoCAD at run-time, this technique is not applicable. Rather it is necessary to instruct the run-time linker (rld) to load the malloc_cv library first when starting AutoCAD. In this manner the debug functions are used.

The debug library can be used as-is, running AutoCAD in a stand-alone mode. Debug messages will be written to stderr and you can control the various memory allocation tracing features via enviroment variables. Alternately, you can run AutoCAD inside the debugger (cvd) and gain additional information. Most notably, if you set a breakpoint at the cvmalloc_error function (cvd> stop in cvmalloc_error) you can see the call stack at the point the error was detected.

Here's a handy shell script to use for debugging memory allocation errors in AutoCAD.

• Save the script to a file (e.g. cvmalloc_acad)
• Make it executable (e.g. chmod +x cvmalloc_acad)
• Adjust settings of the MALLOC_* variables as desired.