incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: _RWSTD_REQUIRES throwing uncaught exceptions in tests?
Date Thu, 20 Mar 2008 15:24:09 GMT
 

> -----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