Release notes for Rational Quantify 5.2 HP-UX 10.20, 11.0

Or, for a final release:

    purify-5.1-hpux    (32-bit)
    purify-5.1-hpux64  (64-bit)

If the two install directories are in your path, then running "purify" will automatically select the correct version, based on the type of program you are linking. The same is true for Quantify.

Even if only one install directory is on your path, auto-selection will occur if both versions are properly installed: Running pure_install on each version will prompt you for the location of the other product.

If you already have your licenses installed and do not choose to run pure_install, you can set up this connection between the two install directories by running the script "pure_link_32_64" in each install directory:

    % cd purify-5.1-hpux
    % pure_link_32_64
	

    % cd purify-5.1-hpux64
    % pure_link_32_64

Auto-selection only works between 32- and 64-bit Quantify from 5.0 onwards. In some situations, auto-selection does not have enough context to tell which version (32 or 64-bit) you need. This is true for the options:

      -help
      -printhomedir
      -test-license
      -version

In these cases, Quantify defaults to the 32-bit version unless you explicitly specify what you want, using the new -ptr64 and -ptr32 options:

    % purify -ptr64 -test-license
    % quantify -ptr64 -printhomedir
    % purify -ptr32 -version
    % quantify -ptr32 -help

Failure to include -ptr<32|64> in these cases may yield the wrong information. For example, you may get the product home directory for the 32-bit product when you wanted the 64-bit product.

These options are NOT necessary during normal instrumentation and viewing operations:

    % purify cc -g -o foo foo.o
    % quantify -view my_app.qv

If you attempt to use the 64-bit Quantify using -ptr64, or by having it on your PATH first, on a non 11.x systems, execution will fail. It only runs on HP-UX 11.x and later.

Because of a defect in auto-selection, auto-selection does not occur when using "-nolink". You must use -ptr64 or -ptr32 to ensure the correct version is used:

    % quantify -ptr32(or -ptr64) -nolink ld mylib.a

• Restrictions on the HP-UX 11.00-wide (64-bit) version of Quantify:
  • Static data checking is not supported.
  • Using Quantify with old versions of the HP-UX linker may cause the install test to fail with an error from the linker saying the "+nodynhash" option is not recognized. You should obtain a newer linker from HP. This option is support by 64-bit linkers from 07-Jan-1999 and later.
  • You may also workaround this problem by include the following in your PUREOPTIONS environment variable:

    -force-no-dynhash=no

    The default setting of this option (to "yes") is used to workaround an HP bug in newer linkers.

  • Shared-library "fini" sections (static destructors) do not run.
  • shl_unload and dlclose are not implemented. When a program attempts to unload a shared library, the call will appear to succeed, but the library will not actually be closed or unloaded. Also, C++ "static destructors" are not run for the library.
  • There is a bug in strlen in the 64-bit libc which causes the example program "hello.c" to get numerous UMR's instead of only one, as you might expect.

  • Quantify will not report system call time spent inside brk or sbrk.

• When a Japanese locale is specified using the LANG environment variable, instrumentation of archive libraries may fail with the message:

  Error: Child process exited with status = 1.

  This is caused by an 'ar' failure in this locale. A workaround is to unsetenv LANG before instrumenting.

Data Collection

• Calls to shl_unload() that would cause the library to be unmapped can cause qv to incorrectly attribute data to the improper functions. Quantify intercepts calls to shl_unload() and prevents libraries from being unmapped.

• The C compiler (cc) does not include full source file pathnames when a file is compiled -g. In this case, Quantify first attempts to find these source files in the directory of the executable. If the source is not available, Quantify then searches the directories in the value of the -user-path option. If it is unable to find the source file after this search, a file dialog is presented for the user to locate the source file.

User Interface

• Under most window managers, if a non-explicit focus policy is used, qv can steal the focus from a non-qv window. Click on the window title to reestablish proper focus.

• Under twm and tvtwm, Quantify dialogs can be iconified. Once iconified, however, they cannot be de-iconified and qv will no longer respond. You should avoid iconifying dialogs under these window managers.

• Under vuewm, the window manager fails to update the border of the window that has current focus after a menu has been used. Click on a window to reestablish proper focus. Alternatively, set the following X resources in your .quantify.Xdefaults file:

         vuewm*enforceKeyFocus: False
         *OI*wmIgnoresPPosition: True
  

  Under vuewm, de-iconifying one window from a different window on a different virtual screen makes a copy of the de-iconified window on the current virtual screen as well as de-iconifying the window on the previous virtual screen.

• There is a bug in version 3.3 of the OpenWindows X server shipped with Tadpole SPARCbooks. The server loses track of a client application's Graphics Contexts (GCs) after the first time the GCs are used. As a result, among other things, buttons and menus of client applications which are supposed to be greyed out don't look greyed out.

  You can see the same bug in other X applications such as xterm. In xterm, use control-middle-click in the xterm window to pop up the xterm VTOptions pop-up menu. Notice that the menu item "Show Alternate Screen" (close to the bottom of the menu) is greyed out. Now let go of the menu (without selecting anything), and popup the menu again. Note that the same menu item is no longer greyed out.

• The Quantify GUI menus and buttons become inaccessible if either the NumLock or ScrollLock key is activated. The workaround is to switch them off, or add the following line(s) to your $HOME/.Xdefaults file.

      ! Ignore the NumLock and ScrollLock keys on 
      ! mouse buttons
      Quantify*ignoreModifierMask: Mod3|Mod2
   

  This second workaround will take effect for a new Quantify viewer after you restart your X-session or run a command like 'xrdb -merge $HOME/.Xdefaults'.

Compilers

• FORTRAN routines with multiple entry points are not supported when compiled -g.

• FORTRAN routines with formatted READ or WRITE statements which use the END= or ERR= specifiers are not supported when compiled -g.

• The GNU gcc extensions are not tested against Quantify. Most gcc extensions will probably work fine. Known limitations at present include problems with nested functions (e.g.: making a pointer to a nested function and attempting to call through it will not work).

• Quantify supports the aCC compiler from HP but there is a required patch: for HP-UX 10.01 through 10.10, use PHSS_14507. For HP-UX 10.20, use PHSS_17689. For HP-UX 10.20 you also need PHSS_17225.

• When using the aCC compiler from HP, time spent in constructors will be counted at function granularity, even if compiled with the -g option. Also, time spent in constructors can be assigned to three separate functions; for a class called MyClass the time might be split among the functions MyClass::MyClass, MyClass::MyClass%1, and MyClass::MyClass%2. The true time is the sum of these times.

• C revisions 9.61 through 9.65

• These compilers generate incorrect debugging information for some functions. Programs compiled using these compilers may not be debuggable after translation. In this case Quantify may produce a message beginning "Failure relocating..." Additionally Quantify may not be able to attach performance information to specific line numbers in such cases. HP patch PHSS_4923 corrects this problem.

• Exception handling

  g++ 2.7.2 exceptions are not supported.

Debuggers

• XDB & Softdebug
  • Use <quantifyhome>/quantify_xdb to invoke xdb on an instrumented program.

  • An instrumented program receives a signal 18 (death of child) during its initialization. Place "z 18 sir" in your ~/.xdbrc file to suppress this warning. Failure to suppress the warning will sometimes cause xdb to fail.

  • XDB, when debugging a program that uses shared libraries, reads the symbol table from /lib/dld.sl. However, Quantify has changed your program to use an instrumented version of dld.sl. The symptom of this mismatch is the message:

  •          Wait...loading shared-library map tables.
             xdb panic: Mapped addresses for dld
    	      overlap text segment for dld
    

    There is a simple workaround for this problem and we've implemented it in the shell script <quantifyhome>/quantify_xdb. Whenever you use xdb on an instrumented program use this script to invoke xdb.

  • Typing ^C while running an instrumented program under xdb requires caution. There is a high probability that the interrupt will occur inside the code Quantify has added to your application. If this is the case, you must single step or set a breakpoint and continue before you attempt to call any subroutines (the Quantify API is an example).

  • The XDB single stepping command, 's' sometimes fails to find the next source line. When this happens, usually near a subroutine call, program execution continues until the next breakpoint. The 'S' command is always reliable.

• DDE - Distributed Debugging Environment
  • The DDE debugger at release 2.10 has been used with instrumented programs. The shell script: <quantifyhome>/quantify_dde implements one of the workarounds.

  • Instrumented programs get a SIGCHLD signal at program initialization. One workaround is to just hit "go" when the program stops. The following commands added to a .dderc file also help:

    	prop system -on
    	alias `after_debug delete intercept signal SIGCHLD; \
    	  prop system -off; \
    	  breakpoint -in main -entry -exit; \
    	  go
     
    

Old Style Fixups

Quantify does not support a type of relocation information known as "old style fixups". These were generated by HP-UX system software before release 3.0. If Quantify detects old style fixups the message: Object file has incompatible format (may be older than HPUX 3.0) is generated. We have seen this problem with HP's libsql.a and some of Oracle's Oracle6 libraries.

There is a simple workaround. Given a problem object module (or modules) the workaround is to have /bin/ld build a new object module. Suppose the old object modules are called `foo.o' and `bar.o'. Issuing the command:

       % ld -r -o new_foo.o foo.o
       % ld -r -o new_bar.o bar.o
  or
       % ld -r -o foo_and_bar.o foo.o bar.o
  

would generate a new object module where the old style fixups have been removed.

In the case of an archive file the following script will create a new archive given the full pathname of the original:

      #!/bin/sh
      # Remove old fixups from an archive.
      # Supply original .a name as first argument.
      cd /tmp
      lib=new_`basename $1`
      ar x $1
      rm -f $lib
      for member in `ar t $1` ; do
          ld -r -o _$member $member
          ar q $lib _$member
          rm $member _$member
      done
      echo Created `pwd`/$lib
	

Threads

• Customers using unsupported threads packages should contact Rational Software technical support (support@rational.com) to ensure compatibility.