Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <472B77AB.7000506@roguewave.com>
Date: Fri, 02 Nov 2007 13:16:59 -0600
From: Martin Sebor <sebor@roguewave.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.8) Gecko/20071009 SeaMonkey/1.1.5
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: 19.exceptions.mt.cpp fails on AIX
References: <13551223.post@talk.nabble.com>
In-Reply-To: <13551223.post@talk.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Travis Vitek wrote:
> 
> I'm working on fixing an issue with test 19.exceptions.mt.cpp on AIX. The
> issue is that the test spins in a loop because the loop counter is being
> thrashed when an exception is copied onto the stack. Here is a simple
> testcase.
> 
> #include <exception> 
> 
> void test_single_exception ()
> {
>     for (int i = 0; i < 5; ++i) {
> 
>         try {
>             throw std::exception ();
>         }
>         catch (std::exception ex) {
>             &ex;
>         }
> 
>     }
> }
> 
> int main ()
> {
>     test_single_exception ();
>     return 0;
> }
> 
> So the issue is actually not that complicated. The exception type provided
> by STDCXX is 4 bytes in size, and the native one is 8.

Yikes! That's very bad!

> In and of itself,
> that shouldn't really be a problem because the two definitions should never
> coexist, right?

Unfortunately, they do. All the exceptions thrown by the runtime
(bad_alloc, bad_cast, bad_exception, and bad_typeid) derive from
std::exception. So the runtime has one view of the exception
objects it throws but a program that uses stdcxx sees them
differently.

> So the problem really shows up when the config tests run,
> they set the following macros...
> 
> #define _RWSTD_NO_EXCEPTION_ASSIGNMENT
> // #define _RWSTD_NO_EXCEPTION_COPY_CTOR
> #define _RWSTD_NO_EXCEPTION_DEFAULT_CTOR
> #define _RWSTD_NO_EXCEPTION_DTOR
> #define _RWSTD_NO_EXCEPTION_WHAT
> 
> If I'm reading the code correctly, this means that STDCXX will provide
> definitions for the default ctor, copy-assignment operator, dtor and what().

Right.

> The definition of the copy-ctor will come from somewhere else [where?].

 From the xlC runtime library, libC.a.

> Anyways, an exception is created and copied out for the unwind. The
> exception is then copied back onto the stack at the location the exception
> is handled. The code that actually copies the exception expects the object
> to be 8 bytes in size, but the code that created the exception only
> allocates 4 bytes for it.
> 
> So here is my problem with all of this. How is this safe?

It's not. It's a serious bug in our library. Somehow we're missing
a data member in std::exception that the xlC runtime library defines.

> If the one of the
> 'special' functions provided by the system has some side effect, and we use
> that implementation, then how can we safely define any of the other
> 'special' functions?

The assumption/hope is that the functions are straightforward and
have no side-effects.

> 
> That said, what is the appropriate solution? Should we just pad the type out
> to the correct size,

Yes. As Farid says, the XLC exception and ours must have the same
size.

> or should we provide our own definition of the copy
> ctor, possibly looking at the compiler test to verify it is not wrong. Both
> seem to work quite well, but I'm afraid I don't understand why we opt to use
> the definitions of the 'special' functions that are provided. I guess I
> would understand if I had got a linker error complaining of mulitply defined
> symbols, but I don't.

This (the interface between the language runtime and the library)
is the most difficult area of the library for independent library
authors like us to get right. We can't help but make assumptions
about the runtime. Some are based on our inspection of the native
library headers (which may change in subtle but sometimes
important ways from one release to another), others we try to
automate (the detection of the special member functions of the
exception classes). Both approaches are fraught with peril.

Martin