You can set breakpoints, examine the stack, resume execution, or carry out any other normal debugger commands.
You can set breakpoints in any function with an entry point known to your debugger. Valid functions include internal functions and the UDRs in your shared-object file. The database server is compiled with debugging support turned off, so local storage and line number information is not available for UDRs. However, because you compiled the shared-object file for debugging, you can see line number information and local storage for your functions.
The database server routine that calls functions in your shared-object file is named udr_execute( ). When you enter a command in the client application that calls one of your UDRs, the debugger stops in the udr_execute( ) routine. You can then step through your UDR. Because your shared-object file is compiled with debugging support, you can view the local variables and stack for your functions.
On UNIX or Linux, you can set a breakpoint in the debugger utility on the udr_execute( ) function as follows:
stop in udr_execute cont
When you need to debug a UDR, keep the following considerations in mind:
The database server writes status messages to the message log file. By default, this file is named online.log. You can change the name of this file with the MSGPATH configuration parameter.
The database server puts these trace messages in a trace file when the UDR executes. For more information, see Using Tracing.
Good test cases are as simple as possible.
If your execution environment includes DataBlade modules, you might want to first attempt debugging without these DataBlade modules so that the environment is as simple as possible. However, if this is not possible, make sure that you install and register any DataBlade modules that affect the execution of the UDR you are debugging. To install and register other DataBlade modules, such as the DataBlade modules included with Dynamic Server, see the instructions that accompany them.
Memory errors are usually caused by overrunning memory in a UDR. To avoid common causes of memory errors in a UDR, make sure you meet the following memory-handling requirements.
| Memory-Handling Requirement | More Information |
|---|---|
| Do not return the NULL-valued pointer from a UDR. | Returning a NULL Value |
| Do not use null-terminated strings as data in a varying-length structure such as mi_lvarchar. | Varying-Length Data and Null Termination |
| Do not return local variables from a UDR. | Returning a Value |
| Make sure that you handle data types for parameters and return values with the correct passing mechanism. | MI_DATUM Arguments and Returning a Value |
| Make sure memory that a UDR allocates is of the appropriate memory duration for its use. Do not access memory after its duration has expired. | Choosing the Memory Duration |
The database server resolves undefined symbols in a shared-object file when it loads the shared-object file. If a symbol is missing, the load fails on the first execution of the UDR, and the database server writes a message in the log file. Symbols defined in two different shared-object files are distinct entities and do not resolve against each other.
A symbol defined in both a shared-object file and the Dynamic Server main module behaves in one of two ways: