Problems and Limitations

General limitations of HP DDE

HP DDE does not debug the following types of code:

Displaying Information for Classes in a Shared Library (aC++)

When working with the HP aC++ compiler, HP DDE cannot display the class information for the classes defined in a shared library. However, aC++ applications compiled with -g0 can be debugged by DDE. In this instance, DDE displays the class information in shared libraries for all of the classes except for the classes with a virtual function.

For example, given the class Cfoo defined in a shared library:

     class Cfoo
     {
         public:
                  Cfoo(const char* data=0);
                  virtual -Cfoo();
                    unsigned long m_length;
      };

and an instance defined in the executable:

      Cfoo foo("Hello world!");

you would specify its type definition to print the 'foo' virtual function, as shown below:

dde> pri (Cfoo)foo

(record): (record)
.__vfp: 7AD29088
.m_length: 12

	NOTE: An alternate way to display class information would be to link the module that has the definition of the class into the executable for debugging instead of putting the definition into the shared library.

HP DDE and Compile-line -g option Limitations

HP DDE encounters a limitation with source files that are compiled with the -g option. If a source file includes an external declaration for a variable that is declared within a file that is not compiled with -g, and if that variable is not used in the first source file, then HP DDE handles the variable as a pointer. If that variable is used in the first source file, then DDE handles the variable correctly.

HP DDE and Emacs Escape Characters in ksh Mode

HP DDE uses % (percent sign) instead of a \ (backslash) for emacs editing in ksh mode.

HP DDE Limitations with a SIGSTOP Process

HP DDE cannot adopt a process which is stopped with SIGSTOP.

HP DDE Specifying the System automount Prefix

HP DDE uses /nfs as the AUTOMOUNT PATH. If the AUTOMOUNT PATH is configured to be something other than /nfs, DDE still uses /nfs.

For example, if AUTOMOUNT PATH is configured as /net, DDE uses /nfs instead of /net.

This might cause a problem when you choose the File menu item Load Executable, which may display an incorrect path name in the executable name field of the resulting window.

To prevent the incorrect path name, you must change the AUTOMOUNT PATH to the value used on your system.

HP DDE Behavior of the Step and Signal Handler

If a signal is delivered to a target process when DDE attempts to single- step or step-over the process, and if DDE does not intercept the signal, then DDE prints a message and continues normal step execution.

	NOTE: The "next" statement may be the same statement that you just tried to step past. It may also be the start of the signal handler if the signal handler is compiled with -g. DDE does not distinguish between a statement that loops back on itself or a statement that was interrupted by a signal.

The jump into the signal handling code is treated as a normal call situation. Since the signal handler will return to the first instruction to execute—instead of the following instruction—it may be confusing that a step produced no obvious action.

A step stops when it reaches the first instruction of a debuggable statement. When a signal occurs during the step, that instruction is typically the first in statement the user just attempted to step past. To reduce confusion, when the step routine detects that an interrupt (signal) has occurred while a step was being tried, an informational message is printed in the DDE transcript. This message will indicate that a signal was delivered to the target when the step attempt was made.

For example:

dde> s
Step interrupted by signal delivered to target.
Intercepted event type 'signal SIGCHLD'.
Signal received by process 15619: (SIGCHLD).
Stopped at: handler (hpux_export_stub_norp stub) (0000C058)
dde> tb
'main(5): Stopped at: handler (hpux_export_stub_norp stub)
(0000C058)
'main(4): Called from: _sigreturn (C02033B0)
'main(3): Called from: \\sigact\main\12
'main(2): Called from: _start+00a0 (C0140114)
'main: Called from: $START$+0198 (0000B290)

HP DDE Problem when Debugging Program with Stack Overflow

When debugging a program with a stack overflow, HP DDE may appear to hang. In fact, HP DDE has not hung but can take several minutes to process the overflow. If a stack overflow occurs, the following OS warning appears on the terminal in which HP DDE was invoked (not the target program's I/O window):

Pid <target_pid_number> received a SIGSEGV for stack growth failure. Possible causes: insufficient memory or swap space, or stack size exceeded maxssiz.

HP DDE also displays the following message in the transcript window:

Intercepted event type 'signal SIGSEGV'

These messages appear immediately after the stack overflow. HP DDE then appears to hang.

The workaround for this problem is to wait. Unfortunately, the wait could be several minutes. Once HP DDE has processed the event, the traceback command gives incomplete information. However, you can still use other commands such as the env command to move up and down the stack, or print to examine variables.

Another way to determine where the stack overflow occurred is to interrupt DDE and issue the print `pc -hex command. Then issue the restart command and the env `va(<pc value>) command will take you to the instruction where the overflow occurred.

HP DDE Warnings when Setting Breakpoints in HP aC++ Inline Functions

HP DDE may generate warnings if you set breakpoints in an aC++ application's inline functions. The following messages may result:

(Warning) Location "\\on_off_switch::turn_on" is inline; no address information available.

(Warning) Location "\\on_off_switch::turn_off" is inline; no address information available.

To solve this problem, turn off inlining by recompiling the aC++ code with the +inline_level 0 or +d options, as shown below:

$ aCC -g +inline_level 0 -o t25_a t25.C

HP DDE Limitations with Fortran 90 LBOUND and UBOUND

HP DDE currently has the following limitations regarding the Fortran 90 LBOUND and UBOUND intrinsics:

HP DDE call Command Problem with C++

There is a known problem with the HP DDE call command when used to invoke functions translated using the HP C++ compiler that have float arguments. The debugger will pass the float value in the wrong floating point register.

The workaround for this problem is to make sure programs are compiled using the +a1 switch. This switch will direct the compiler to pass float arguments as float instead of promoting them to double.

HP DDE Limitation Regarding Use of C++ typeid Operator

The typeid operator will not work in HP DDE command expressions. For example:

print typeid(*a).name()
"type_info" not found in current environment.
type_info class symbol information unavailable.
typeid information unavailable for this type.

As a workaround, you can use the describe command to get a verbose description of an expression's true dynamic type. For example:

describe *a

HP DDE Problem with Setting Breakpoints at the PC Location

If you choose the menu item Break: Set at PC, a Breakpoint(s) set message appears in the Debugger Output Area, but no breakpoint symbol appears in the Annotation Margin of the Source File Area. This breakpoint is set at the assembly level only.

Invoke Show: Assembly Instructions to see where the breakpoint is set. The breakpoint symbol appears in the Annotation Margin of the Assembly Instructions display.

HP DDE Problem with Window Size

If you have defined the X resource DDE.geometry for an earlier version of HP DDE, remove or comment it out of your X resources when you move to HP DDE 4.x. Otherwise, you are likely to find that the main debugger window is an inappropriate size and that DDE has ignored the DDE.mainX and DDE.mainY resources in the .ddeguirc file.

HP DDE Register Windows Problem

If you choose the menu items Show: Registers->General... or Show: Registers->Special..., the window displayed may be too wide to fit on the screen. Resizing the window does not fix the problem.

The two alternatives to address this problem are:

HP DDE Problem with On Item Help

HP DDE may be unable to display help when you choose the menu item Help: On Item. Instead, HP DDE displays the error message:

A request to the help server failed.
The desired help is not available.

This problem appears to occur more frequently if you select Help: Overview before Help: On Item. You may choose to select Help: On Item when you first invoke HP DDE if you expect to access Help: On Item later in your debugging session.

HP DDE Problem with step -until Command in Optimized C Code

If you use the step -until command (or Execution: Step
Operations->Step Until) to step to a line that resolves to more than one instruction, the debugger will reach only one of the multiple instructions. This problem is likely to occur, for example, in unrolled loops.

The workaround for this problem is to set a breakpoint at the same line, and then to use the step -return command (or Execution: Step
Operations->Step Out). This workaround allows you to continue to use the step command for highlighting.

HP DDE Problem With vfork()

You cannot single-step over a vfork() call. If you try to single-step, the target program will fail. A workaround is to set a breakpoint after the vfork() call. Then issue a go command instead of single-stepping to get past the vfork() call.

HP DDE Problem with Pascal Uplevel References

HP DDE will always pick the most recent stack activation to display uplevel references when direct or indirect recursion is used. This may cause HP DDE to display uplevel variables with a value that is different from the value seen by the function.

HP DDE Problem with Purify'd Code

During a debugging session on executables produced by Purify software (a product of Pure Software Inc., now a division of Rational Software Corp.), the application may receive a SIGCHLD signal and stop executing before reaching the main entry point. Issue a go command to proceed to the main entry point.

HP DDE Limitation with Implicitly Loaded Shared Libraries

HP DDE currently does not allow you to intercept the loading of implicitly loaded shared libraries (libraries that are linked with your program).

Since some implicitly loaded shared libraries contain code that is executed before the main program actually starts, you may be unable to set breakpoints in that code. This problem typically arises when you try to set a breakpoint on a C++ constructor function for a global object.

A workaround for this problem is to stop the debugger in start-up system code and then to load debugging information for the implicitly loaded shared library. The following example illustrates the details for this workaround.

HP DDE and HP PAK Limitation on Short File Name Systems

HP DDE and HP PAK will not run from file system partitions configured for short file names.

HP-UX file systems configured for short file names truncate file names to 14 characters. Some of the file names in the HP DDE and HP PAK products exceed 14 characters in length.

Make sure that HP DDE and HP PAK are installed on file system partitions that support long file names. The default on HP-UX 10.x and 11.x systems is to support long file names.

To enable long file names, see the manual HP-UX System Administration Tasks.

HP DDE Error Log File Missing

HP DDE writes internal diagnostic information to the file /var/opt/dde/dde_error_log. This is a text file containing DDE diagnostic messages that might be useful to your HP support representative. If you get a message from DDE that this file is missing, you can create the file by logging on as root and using the touch command on the file /var/opt/dde/dde_error_log and then start DDE.

HP PAK Puma Problem with Source Click-Back

You cannot view the source code associated with the current stack trace in this version of Puma. This feature is mentioned in the online documentation for the Pan/Zoom and Call Tree Analysis windows. However, when you click on a graph with the left mouse button, the source code display will not appear.

HP PAK Puma Problem Attaching to Program's First Child

The Attach to program's first child option on the Choose target program for data collection window currently does not work.

A workaround is to use the ps command to learn the process id (pid) of the child program, and then use the Attach to running program choice to attach to this pid.

HP PAK Puma X Server Hang During Data Collection

Running HP PAK Puma in graphics mode while collecting performance data on a graphics-intensive application is likely to hang the X Server. Use either of the following workarounds:

% puma -text
puma> monitor -invoke application-name

HP PAK Puma Limitations Regarding Next Run of a Program

When using Puma to attach to the next run of a target program, be aware of the following limitations:

HP PAK Puma Problem with Signal Blocking and Multiple Threads

Any situation in a multi-threaded program that blocks the receiving of signals will distort Puma's sampling interval, resulting in deceptive spikes of resource usage. While the total resource usage will be correct, the actual time between samples will be longer than the expected interval.

Some situations where signal reception will be blocked include:

To determine whether high resource use is really a performance problem or just the result of signal blockage, examine the change in system and user cycles during the sample interval.

HP PAK Puma Problem with Selecting Thread Type

Selecting a thread type of Single-Threaded or User-Threaded if the target program has multiple kernel threads will cause Puma to hang.