incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
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:
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:Travis.Vitek@roguewave.com] Sent: 
>>> Wednesday, March 19, 2008 10:50 PM
>>> To: dev@stdcxx.apache.org
>>> 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.
>>
> 
> 


Mime
View raw message