IY94572: Destructor called twice on exception

October 2008 XL C/C++ Enterprise Edition V7.0 for AIX PTF
June 2009 XL C/C++ Enterprise Edition V7.0 for AIX PTF
June 2008 XL C/C++ Enterprise Edition V7.0 for AIX PTF
July 2007 XL C/C++ Enterprise Edition V7.0 for AIX PTF
December 2007 XL C/C++ Enterprise Edition V7.0 for AIX PTF
March 2008 XL C/C++ Enterprise Edition V7.0 for AIX PTF
April 2007 VisualAge C++ Professional V6.0 for AIX PTF

APAR status

• Closed as program error.

Error description

• A new statement that uses a number of compiler-generated
  temporaries in, or after, which an exception may be thrown,
  e.g.:
  MyManaged * mp;
  Foo foo(42);
  mp = new MyManaged(new Bar(Foo(foo).toBar()));
  throw 1;
  
  In this case both the temporary Foo from 'Foo(foo)' and the
  temporary Bar from 'Foo(foo).toBar()' are destroyed twice.
  Once after the assignment of the new object to mp, and a second
  time after the throw.
  

Local fix

• Use an inline function to hide complex constructions,
  e.g.:
  inline Bar * hide_complex_creation(const Foo & f) {
    printf("hide_complex_creation(const Foo &) ... f=%#llx\n", f);
    return new Bar(Foo(f).toBar());
  }
  ...
  MyManaged * mp;
  Foo foo(42);
  mp = new MyManged(hide_complex_creation(foo);
  throw 1;
  

Problem summary

• Users who use eh=v6, who have code that may
  throw an exception within code with more complicated
  "new" expressions.  These new expressions have
  compiler generated temporaries as parameters in the new
  expression, or have more complex expressions like
  nested new expressions that cause more exception
  handling state changes during the creation of
  temporaries.
  
  (Note: -qeh=v6 is the default for XL C/C++ V7 and V8)
  
  During the processing of the exception
  handling state changes, in a new expression the state
  changes are cloned so that there could be one path for
  when the ctor may throw an exception, and one path
  for when the ctor does not.  There was an error in
  the cloning mechanism where the assumption of the
  state unwinding was to be linear, whereas in actuality
  the unwinding was more complicated and would jump
  around to different states.  We needed to match this
  behaviour during the cloning phase.
  
  Potentially a sigabort at runtime will occur because
  the unwinding of the states is incorrect causing a
  destructor to be called twice.
  

Problem conclusion

• The cloning mechanism for state tables has
  been modified to correctly clone the set of state
  table entries that are generated for the new
  expression.  The linear unwind mechanism (by assuming the
  currentState is the last state that was cloned in the
  iteration) was an incorrect assumption.
  

Temporary fix

Comments

APAR Information

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

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

  IY99560

Fix information

• Fixed component name

  VA C++ PROF FOR

• Fixed component ID

  5765F5600

Applicable component levels

• R600 PSY U811611

     UP07/04/30 I 1000

IBM, the IBM logo and ibm.com are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.

Product categories:

Software

Software Development

Analysis, Modeling, Design & Construction

VisualAge C++

Compiler

Software version:

600

Reference #:

IY94572

IBM Group:

Software Group

Modified date:

2007-06-22