Debugging a DataBlade module
Debugging a DataBlade module is usually an iterative process, repeated many times until the code is debugged.
The debugging process has the following general steps:
- Build the shared object file with debugging support while
logged on as user informix (if necessary).
To debug a DataBlade module, compile the shared object file with the -g compiler option so that debugging symbols are available to the debugger. See Compile DataBlade module code for information about compiling with debugging support.
- Install the DataBlade module shared object and SQL scripts in the $INFORMIXDIR/extend/project directory. See Installing a DataBlade module for more information.
- Start your database server with the oninit command, while logged on as the informix user. See the HCL Informix Administrator's Guide for more information.
- Register the DataBlade module by using BladeManager (if necessary). See Register a DataBlade module for more information.
- If you are replacing an existing shared object, shut down and restart the database server with the onmode -yuk and oninit commands. See Replace a shared object file for more information.
- Load the DataBlade module by calling one of its routines. See Load the DataBlade module for instructions.
- Log on as user root in a new window to run the debugger.
- Obtain the database server process ID for the root session. See Identify the server process for instructions.
- Run the debugger and attach to the database server process. See Run the Solaris debugger for instructions.
- Set any appropriate breakpoints. See Set breakpoints for more information.
- Issue SQL statements to call your DataBlade module routines from the informix session. See the IBM Informix DB-Access User's Guide for more information.
- Edit the source code (if necessary).
- Repeat the procedure, as necessary.
- Load the DataBlade module
Before you can attach to the database server process with the debugger, load your DataBlade module shared object file into the database server address space. With the shared object file loaded, set breakpoints on the routine entry points and examine local storage provided by the routines. - Identify the server process
To debug a routine, you must identify the virtual processor in which that routine runs. By default, routines are assigned to the CPU virtual processor class. However, when you create a routine in BladeSmith, you can specify if it is poorly behaved and assign it to a user-defined virtual processor class. - Run the Solaris debugger
To debug your DataBlade module, use a debugger that can attach to the active database server process and access the symbol tables of dynamically loaded shared object files. On Solaris, the dbx utility meets these criteria, as does debugger. - Set breakpoints
You can set breakpoints in any routine with an entry point known to dbx.
Parent topic: Debugging and testing DataBlade modules on UNIX