IBM Support

PM88150: DLOPEN RETURNS A VALID HANDLE FOR A NON-DLL OBJECT

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as fixed if next.

Error description

  • dlopen() is returning a valid handle for a
    non-DLL.  This occurs for a z/OS XL C program
                     built as a non-DLL - yet the documentation
                     states that for dlopen: "NULL is returned if
                     the target file is not in correct DLL
                     executable format."
    
                     Stated differently: dlopen() against a non-DLL
                     C program results in:
                       dlsym failed: CEE3591I DLL tdlopen does not
                       export any symbols.
                     This conveys that the target program is a DLL.
    

Local fix

  • Not applicable.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: Applications using the z/OS XL C/C++         *
    *                 run-time library to make explicit DLL        *
    *                 calls and that test the return value         *
    *                 from dlopen() or dllload() for the           *
    *                 presence of a valid dll handle.              *
    ****************************************************************
    * PROBLEM DESCRIPTION: The internal load service for DLLs      *
    *                      does not check for the presence of      *
    *                      exported symbols when handling          *
    *                      explicit calls from dlopen().           *
    *                      Instead, explicit calls rely on         *
    *                      subsequent calls to dlsym() to          *
    *                      establish whether symbols have been     *
    *                      exported from the called DLL.  As a     *
    *                      result, calls to dlopen() may return    *
    *                      a handle rather than NULL, if a named   *
    *                      DLL object can be loaded, even though   *
    *                      it does not export any variable or      *
    *                      function symbols.                       *
    *                                                              *
    *                      Calling applications that test return   *
    *                      values from dlopen() may wrongly assume *
    *                      the named DLL object is a valid DLL.    *
    *                      Whereas a NULL returned from dlopen()   *
    *                      indicates an error occurred or that     *
    *                      the DLL object is not in correct DLL    *
    *                      executable format, a usable handle      *
    *                      does not guarantee that the caller may  *
    *                      import symbols from the loaded object.  *
    *                                                              *
    *                      The same ambiguity exists with respect  *
    *                      to the deprecated dllload() function,   *
    *                      which relies on the dllqueryvar() and   *
    *                      dllqueryfn() functions to determine     *
    *                      whether the named DLL object has        *
    *                      exported variable or function symbols.  *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    See Problem Description.
    

Problem conclusion

Temporary fix

Comments

  • This APAR is being closed FIN with concurrence from the
    submitting customer. This means that a fix to this APAR is
    expected to be delivered from IBM in a release (if any) to be
    available within the next 36 months.
    

APAR Information

  • APAR number

    PM88150

  • Reported component name

    LE C LIBRARY

  • Reported component ID

    568819805

  • Reported release

    770

  • Status

    CLOSED FIN

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2013-04-30

  • Closed date

    2013-05-23

  • Last modified date

    2013-05-23

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

  • R770 PSN

       UP

  • R780 PSN

       UP

  • R790 PSN

       UP

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCVSBD","label":"Runtime"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"770","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"770","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"770","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
23 May 2013