HPlogo HP WDB 5.0 Release Notes: HP 9000 and HP Integrity Systems > Chapter 3 Known Problems and Workarounds

Known Problems on Itanium
» 

Technical documentation

 » Table of Contents

spacerspacerspacer
spacer
spacer
  		 
 

  • When following a child process created using vfork(), you cannot get control of the child process before it execs.

    The earliest you can get control is at the exec point by using the command catch exec. The debugger ignores all breakpoints in the child prior to the exec. If both catch vfork and catch exec are set, only the exec event might be caught.

  • HP WDB may show incorrect information for ptype of a structure that has the same name as a variable, as in this program:

    int XYZ;
     
    int main ()
    {
      struct XYZ {
        int ii;
      } ny;
      XYZ = 10;
      ny.ii = 11;
    }

    When stopped in main(), if you use ptype XYZ (c++ style), HP WDB prints the ptype of the global XYZ, not the struct XYZ defined in this scope.

    The workaround is to use ptype struct XYZ to get the type of struct XYZ.

  • When debugging a program compiled on HP-UX 11i v1.6 with the +noobjdebug option, stepping into a static function may cause the debugger to behave as if next was used.

    The workaround for this problem is to set a breakpoint on the function and then use the step command:

    (gdb) break static_function
    (gdb) step

    This causes the debugger to hit the breakpoint in the function.

    You can also minimize the problem by installing the patches listed in “Software Requirements” and recompiling your program.

  • You cannot execute a function while a system call is interrupted.

    HP WDB may print this message when you attempt to use a command such as print my_function():

    You may not execute a function while a system call is interrupted.

    HP WDB displays the message when your program was interrupted in the middle of a system call, for example, sleep() or read(), by some signal, such as one caused by pressing Ctrl-C. The workaround for this limitation is to use these commands when you see the error:

    (gdb) up
    (gdb) tb	
    (gdb) c
    (gdb) print my_function()

    The command tb is an abbreviation for tbreak, a temporary breakpoint and c is an abbreviation for continue.

    These commands set a breakpoint on the return address of the system call and continue. When the program hits the breakpoint, it will be removed and you will get a debugger prompt. You can now call my_function().

  • Disabling threads can lead to deadlocks in your program that prevent Ctrl-C from stopping your program. If this happens, you might be able to stop your program by using fatal signals such as SIGSEGV or SIGBUS.

    You can use these steps to try to stop your program:

    1. Send this command from another shell.

      kill -SIGSEGV pid

      This causes HP WDB to report the signal and show the command prompt.

    2. At the command prompt, examine the threads.

    3. Enable one or more threads to get out of the deadlock.

    4. Issue signal 0 to continue without delivering the signal to the program.

  • HP WDB cannot properly debug programs compiled with HP aC++ versions earlier than A.05.36.

    HP WDB displays this warning when you try to print information on variables in virtual classes or virtual member functions:

    (gdb) print x
    warning: x ambiguous; using JV::LV::A1::x. Use a cast to disambiguate.
    $1 = 1610612736

    Where x is a element in a virtual class.

    The workarounds include the following:

    • In HP WDB, use the command set old-vtable on, then reload your file with the file command.

    • Use WDB 1.3.02 to debug your aC++ program.

    • Re-compile your aC++ program with HP aC++ version A.05.36 or later.

  • HP WDB does not properly handle a command line call of a function that returns an aggregate consisting of 8 or fewer float or double numbers, all of the same size. The Itanium architecture calling conventions handle these differently than other aggregates.

  • When you have multiple shared libraries with the same function name and you set a deferred breakpoint on that function name, HP WDB sets a breakpoint only in the first shared library loaded that contains the function. HP WDB does not set breakpoints when the given function is defined in any subsequently loaded shared libraries.

    To work around this problem, use the catch load command to take control when HP WDB loads the shared library that contains the function on which you want to set a breakpoint. For example:

    (gdb) catch load libtest1.sl

    The catch load command stops the debugger after the library libtest1.sl loads. You can now set breakpoints on any function in the shared library.

  • The set threadverbose functionality is not available.

Known Problems on PA-RISC Systems

set threadverbose Functionality Not Available

The set threadverbose functionality is not available in HP WDB 3.3.

Limitations of the steplast Command

The steplast command has the following limitations:

  • In C++ applications, if you execute the steplast command at the following line, it steps into the constructor itself:

    string hello = "hello gdb";

  • In C applications, if you execute the steplast command at the following line, it steps into c(), and not into a():

    a(b()) + c(d());

Preventing Program Hangs while Disabling Signals

HP WDB has the ability to detect any occurrence of a signal in your program. You can notify HP WDB in advance what to do for each kind of signal.

Normally, HP WDB ignores non-erroneous signals like SIGALRM (to not interfere with their role in the functioning of your program but to stop your program immediately whenever an error signal happens). You can change these settings with the handle command.

Use caution if you disable all signals from certain processes. Disabling SIGTRAP in your program may cause your program to hang on HP-UX 11.00 and 11.11, because breakpoint events are treated as SIGTRAP signals by the operating system.

HP-UX 11.00 and 11.11 use SIGTRAP to communicate with the debugger. If you disable all signals from certain processes (to allow the signals to be delivered to the right process), your program may hang when you try to debug it.

This behavior occurs because if you disable SIGTRAP, the debugger no longer receives notification of events such as breakpoint hits and loading or unloading of shared libraries. This behavior does not occur with breakpoints and SIGTRAP on HP-UX 11.20 and later versions of HP-UX. This is because of changes in the ttrace calls that the operating system uses to communicate with the debugger.

To prevent this problem, do the following:

Ensure to set the following flag: 

(gdb) set complain-if-sigtrap-disabled on

In addition, ensure that the following warning message is not displayed by the debugger before your program execution halts: 

Warning: Thread %d (in process %d) has disabled SIGTRAPs.
Debugging this thread is probably impossible.
If you do not want to see this message again, use:
"set complain-if-sigtrap-disabled 0"

Debugging an Attached Process may Generate Warnings

If you attach to a program that has not been compiled for debugging, you may see the following warning messages about various registers when you step, request a back trace, or request register information from the debugger, and the process is stopped in a system call:

warning: reading ‘r3’ register: No data
warning: reading ‘r4’ register: No data
warning: reading ‘r5’ register: No data
warning: reading ‘r6’ register: No data

To avoid these warning messages, use the finish command to execute the process until the system call returns.

The reason for this message is that when a process stops at a system call, all registers are not readable by the debugger. The debugger’s call to the system routine, ttrace, returns this message when it tries to access such non-readable registers. The debugger then prints this error message from ttrace.

Shared Library Debug Information Missing in Stripped Program

HP WDB cannot find debug information in dynamically loaded shared libraries if the main program has been stripped. The main program is most likely stripped if HP WDB displays the following message when you load the program.

no debugging symbols found

A workaround is to use this process is as follows:

  1. Load the program to debug.

  2. Use the following command before running your program to prevent autoloading of the debug information for all shared libraries.

    set auto-solib-add 0

  3. Run your program.

  4. After the program loads the relevant libraries, interrupt the program.

  5. Use the following command:

    share .

    This loads the debug information for all the shared libraries that match the “.” pattern. This pattern is for all the shared libraries.

Debugging CMA Programs on HP-UX Version 11.0 and 11.11

To debug CMA programs on both HP-UX 11.0 and 11.11, build the program with /usr/lib/libcma.sl (there is no archive library in /usr/lib).

HP WDB Problem in Stepping Out of Fortran Functions

HP WDB does not reliably step out of functions with both the step and next commands. A workaround is to use the finish command at the end of a function.

HP WDB Fortran Support Limitations

The following Fortran features are not supported:

  • Complex number arithmetic

  • Type casting/conversion

  • Nested routines

  • Module variables

HP WDB Limitation while Debugging C++ Inlined Functions

You must compile with the +d option to turn off inlining if you want to call, step into, or set breakpoints in C++ functions that have been inlined.

For example, you might see the following message while debugging:

(gdb) p bar.head()
Cannot evaluate function -- may be inlined

For the call to succeed, you must compile your code with the +d option to get the correct result. After the +d option is used, the compilation displays the following message:

(gdb) p bar.head()
$1 = 0x4007e6f8 "inline function head called"

HP WDB Limitation in Accessing Virtual Classes

If a virtual class is defined in a shared library that is not compiled for debugging (-g0), the debug information is not available in the executable. If you try to access the class, HP WDB displays the <no data fields> message.

For example, RWCollectableDate is defined in librwtool.sl, which is not compiled with -g0.

The following line creates an object named d3:

RWCollectableDate d3(15,5,2001);

If you try to print the variable or class, HP WDB returns the following message:

(gdb) p d3
$3 = {<No data fields>}
(gdb) ptype RWCollectableDate
type = class RWCollectableDate {
    <no data fields>
}

HP WDB Problem with 64-bit vfork() Debugging

The gdb64 component of HP WDB cannot step over call to vfork() because of an HP-UX limitation. The limitation is fixed in the HP-UX 11.0 Extension Pack, December 1998.

HP WDB Limitation Regarding Catchpoints

If you restart a program using the run command, any catchpoints you have set on C++ exceptions in shared-linked executables are deleted, and a warning message is displayed. You can recreate the catchpoints using the catch command.

HP WDB Limitation on Window Resizing with TUI

HP recommends that you do not resize an hpterm or xterm terminal window while using the Terminal User Interface (TUI). If you do so, the following problems occur:

  • The command window contents and (gdb) prompt are erased. Issue the refresh (ref) command, and then press the Return key to recover the prompt.

  • It is no longer possible to scroll in windows by using the Page Up, Page Down, and arrow keys. You must use the +, -, >, and < commands instead.

HP WDB Needs Linker Patch to Use +objdebug

You need to install the linker patch, PHSS_19866 for HP-UX 11.00 (or a later linker patch), to generate object modules that enable faster linking and smaller executable file sizes for large applications. Refer to your Compiler Release Notes for more details.

Fix and Continue Requires Valid TERM Type

If the value of the shell environment variable TERM is not set, HP WDB attempts to use settings valid for an xterm display. If the value for TERM is invalid, the shell prints the following message:

sh: termtype: not found

You must set the value of TERM to a valid type and restart HP WDB.

Backtrace Request Generates “Out of Memory” Error

If you request a backtrace and one of the functions was called with a very large array as an argument, HP WDB attempts to get memory to hold the array and reports that it is out of virtual memory.The workaround is to use the following command:

set print args off

GUI Editor Windows do not Support Undo

The edit windows that WDB-GUI opens do not have undo functionality.

GUI Leak View does not Display All Items

The update pop-up menu item in Leak View collapses all items, because the memory check of HP WDB does not guarantee consistent leak numbers from subsequent info leaks output.

GUI may Show Incorrect Line Numbers after Fix Command

Fixing the target after deleting lines from current procedure can cause line numbers to be incorrect.

Compiling from Source Fails with Unexpected Symbol Error

When you try to compile gdb from the source available here, it fails to compile and generates the following error:

cc: "../wdb-2.1/gdb/infrtc.c", line 465: error 1000: Unexpected symbol: "mutex".
cc: error 2017: Cannot recover from earlier errors, terminating.

You can safely ignore this compile failure. This error occurs after gdb is built successfully. The error is caused by a reference to an HP-internal header file that is used to build a library that is not required to build gdb.

The compile generates a working gdb binary regardless of this error message.



PA-RISC Debugger Features Not Available in WDB 5.0
  		 


Chapter 4 Compatibility Information and Installation Requirements  
© 2004 Hewlett-Packard Development Company, L.P.