IY80656: Memory leak using newer run-time

December 2006 IBM C++ Runtime Environment Components for AIX
June 2006 IBM C++ Runtime Environment Components for AIX
April 2009 XL C/C++ Enterprise Edition V8.0 for AIX PTF
May 2007 XL C/C++ Enterprise Edition V8.0 for AIX PTF
April 2006 IBM C++ Runtime Environment Components for AIX
December 2006 XL C/C++ Enterprise Edition V8.0 for AIX PTF
April 2006 XL C/C++ Enterprise Edition V7.0 for AIX PTF
July 2007 IBM C++ Runtime Environment Component for AIX
June 2006 XL C/C++ Enterprise Edition V8.0 for AIX PTF
May 2008 XL C/C++ Enterprise Edition V8.0 for AIX PTF
August 2008 XL C/C++ Enterprise Edition V8.0 for AIX PTF
March 2006 IBM C++ Runtime Environment Components for AIX
January 2006 IBM C++ Runtime Environment Components for AIX
February 2007 XL C/C++ Enterprise Edition V8.0 for AIX PTF
November 2007 XL C/C++ Enterprise Edition V8.0 for AIX PTF
August 2006 IBM C++ Runtime Environment Components for AIX
August 2006 XL C/C++ Enterprise Edition V8.0 for AIX PTF
May 2006 XL C/C++ Enterprise Edition V8.0 for AIX PTF
April 2007 IBM C++ Runtime Environment Components for AIX
October 2006 IBM C++ Runtime Environment Components for AIX
April 2010 XL C/C++ Enterprise Edition V8.0 for AIX PTF
June 2011 XL C/C++ Enterprise Edition V8.0 for AIX PTF
July 2009 XL C/C++ Enterprise Edition V8.0 for AIX PTF
October 2009 XL C/C++ Enterprise Edition V8.0 for AIX PTF
January 2006 XL C/C++ Enterprise Edition V7.0 for AIX PTF
March 2006 XL C/C++ Enterprise Edition V8.0 for AIX PTF
February 2007 IBM C++ Runtime Environment Components for AIX
July 2007 XL C/C++ Enterprise Edition V8.0 for AIX PTF
August 2007 XL C/C++ Enterprise Edition V8.0 for AIX PTF
February 2008 XL C/C++ Enterprise Edition V8.0 for AIX PTF
November 2008 XL C/C++ Enterprise Edition V8.0 for AIX PTF

APAR status

• Closed as program error.

Error description

• A binary is compiled with the base V6 compiler (6.0.0.0) and
  linked with the 6.0.0.10 runtime.  This binary experiences a
  memory leak when run on a system with the latest runtime
  (7.0.0.2).
  
  Recompiling and linking with a newer version of compiler and
  runtime, respectively, resolves the issue
  
  The test case below shows increasing number of allocations.
  
  TESTCASE:
  
  #include <cstdlib>
  #include <iostream>
  #include <fstream>
  using namespace std;
  
  int main(int argc, char *argv[])
  {
    int cnt = 1;
    if (argc > 0)
      cnt = atoi(argv[1]);
  
    for(int i = 0; i < cnt; i++)
    {
      ifstream ifsIndex("./testdata.txt");
    }
  
    return 0;
  }
  
  $ xlC_r testcase.cpp -o leak
  $ echo foo > testdata.txt
  
  $ MALLOCTYPE=debug MALLOCDEBUG=report_allocations,stack_depth:30
  ./leak 10 | c++filt |  grep
  "std::locale::_Locimp::_Locimp(bool)" | wc
  
  $ MALLOCTYPE=debug MALLOCDEBUG=report_allocations,stack_depth:30
  ./leak 20 | c++filt |  grep
  "std::locale::_Locimp::_Locimp(bool)" | wc
  
  $ MALLOCTYPE=debug MALLOCDEBUG=report_allocations,stack_depth:30
  ./leak 30 | c++filt |  grep
  "std::locale::_Locimp::_Locimp(bool)" | wc
  

Local fix

• Recompiling and linking with a newer version of compiler and
  runtime, respectively, resolves the issue.
  

Problem summary

• There was a change which modified the enum _FROZEN (used by the
  basic_string reference counter) from 0 to 255 for multithreaded
  mode to allow for certain code improvements. The change was
  implemented in 6.0.0.4. Therefore, multithreaded applications
  compiled with 6.0.0.3 or earlier have _FROZEN=0 built into their
  executables and/or libraries. Multithreaded applications
  compiled with 6.0.0.4 or later have _FROZEN=255 built into their
  executables and/or libraries.
  
  In the 6.0.0.3 and earlier versions of xstring.t header file,
  template function _Grow is expanded inline into users' code.
  This function checks if the string reference count is equal to
  _FROZEN. If yes, it does not create a new basic_string object.
  If no, it creates a new basic_string object - this is the
  expected behavior. However, because now the reference count of
  string (255) is not equal to _FROZEN (0) a new string object is
  created, pointed to by the _Locimp object. The string object
  that was previously pointed to by the _Locimp object becomes a
  dangling object. This causes the memory leak.
  

Problem conclusion

• Both the enum _FROZEN and the inline function _Grow are built
  into the users' code -  this cannot be changed without
  recompilation. The fix was to change the reference count of this
  particular basic string object and make it equal to the value of
  enum _FROZEN. This eliminates the creation of dangling object.
  
  Note that in order to use the fix you must set the environment
  variable IBM_STR_OLD_REFCOUNT. For example in ksh:
  
  export IBM_STR_OLD_REFCOUNT=1
  

Temporary fix

• If possible recompile the affected program using the
  following levels of C++ standard library header files and
  runtime library:
  
  - vacpp.cmp.include 6.0.0.4 or later
  - xlC.aix50.rte to 6.0.0.8 or later
  

Comments

APAR Information

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

  IY75895

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

Fix information

• Fixed component name

  XL C++ FOR AIX

• Fixed component ID

  5724I1100

Applicable component levels

• R700 PSY