Martin Sebor wrote:
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).
FWIW, here's some background on this issue I found online:
http://lists.apple.com/archives/xcode-users/2006/Feb/msg00049.html
http://www.dribin.org/dave/blog/archives/2006/02/10/gcc_exception_bug/
http://gcc.gnu.org/ml/gcc-help/2007-10/msg00239.html
http://tinyurl.com/2vx7rc
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.
