There are some platforms where an exception thrown from a shared
lib can't be caught in another executable. I vaguely recall that
OS X may be one of them (maybe only under certain conditions).
Martin
Eric Lemings wrote:
-----Original Message-----
From: Travis Vitek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 19, 2008 10:50 PM
To: [email protected]
Subject: RE: _RWSTD_REQUIRES throwing uncaught exceptions in tests?
Eric Lemings wrote:
Greetings,
I've been stepping through one of the string tests. The
std::string::at() member function is being called with a __pos value
that is >= size() causing the _RWSTD_REQUIRES assertion to fail. It
seems to be throwing an exception, which is not being caught, as a
result. Consequently, the whole test program raises an ABRT signal.
There are several such programs raising ABRT signals (on the Mac
platform at least).
Yeah, I looked at the build results for 21.string.access, and
it doesn't appear to be failing for this same reason on any
other platforms.
One thing I noticed while looking at this is that the
X-Platform view doesn't show all tests. As an example, the
21.string.access test appears in all of the standard results
pages [http://people.apache.org/~sebor/stdcxx/results/], but
it doesn't appear in the X-Platform view
[http://people.apache.org/~sebor/stdcxx/results/builds].
Maybe this is something that Martin should look at. Martin?
Now there's certainly nothing wrong with the test case testing
out-of-bounds behavior but it should be catching any possible
exceptions, shouldn't it? Assuming the std::string::at() function
does not have a no-throw guarantee.
I'm assuming that you are asking why there is no catch (...)
block to eat all exceptions. I don't really have a good
answer for that.
I think that since the string implementation is only supposed
to throw std::length_error and std::out_of_range, it may be
acceptable to catch only those exceptions in the test for
string. Of course some other exception may be thrown
indirectly [ex. std::allocator<T>::allocate() may throw
std::bad_alloc], but those cases should probably not be
exercised by the string test.
If the problem is what I think it is, adding a catch all
probaly won't help. I'm _guessing_ that the definition of
std::exception [which is based on output of config tests]
isn't consistent with what is provided by the runtime library.
Actually there is a catch block. After digging some more, I believe
the problem is that another exception is being thrown while the
first out_of_range exception is being constructed.
I noticed a buffer overrun for the __rw_what_buf array. Its size is
256 characters (src/exception.cpp, line 436) but the string it held
was way more than this. (Need to replace that hard-coded 256 constant
with a macro define at least.) I increased its size but that didn't
solve the problem. I do know that the what argument (passed to the
_C_assign() function) is getting corrupted (overwritten) with junk
at some point.
Still digging...
Brad.
