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:30:10 GMT
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: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