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