stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: _RWSTD_REQUIRES throwing uncaught exceptions in tests?
Date Thu, 20 Mar 2008 15:38:07 GMT
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:

> Martin
> Eric Lemings wrote:
>>> -----Original Message-----
>>> From: Travis Vitek [] Sent: 
>>> Wednesday, March 19, 2008 10:50 PM
>>> To:
>>> 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 
>>> [], but it doesn't 
>>> appear in the X-Platform view 
>>> []. 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.

View raw message