From dev-return-7090-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Thu Mar 20 15:30:47 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 44340 invoked from network); 20 Mar 2008 15:30:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Mar 2008 15:30:47 -0000 Received: (qmail 25809 invoked by uid 500); 20 Mar 2008 15:30:45 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 25787 invoked by uid 500); 20 Mar 2008 15:30:45 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 25778 invoked by uid 99); 20 Mar 2008 15:30:45 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Mar 2008 08:30:45 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates 216.239.58.190 as permitted sender) Received: from [216.239.58.190] (HELO gv-out-0910.google.com) (216.239.58.190) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 20 Mar 2008 15:30:06 +0000 Received: by gv-out-0910.google.com with SMTP id e6so290610gvc.33 for ; Thu, 20 Mar 2008 08:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; bh=qT8fDHCyirv7A8U3JoBivjaCQl1b0SBkP/1XfAd0TF8=; b=MbIF4N7KtwSHs6Yo0H2nxI87S+6YgGaRTF35PZaMOg+AzNsbYJfqhKGMHXXXjwqeAfRSq6UQxcUgTYiI3tqhjlqYs+xQVzy90b1ceiyNBio/vsqblKkiFi+p6FzRzSfkJqHVUUE/PHZVdZxXyruURo8GxkOYcUW6Ou+To/K/pNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=o8crV1HitcRknUKoMSdS1x4FCODCatVXXwumlQMCy99j0iwu20xX/7Pud8C2S0KTr8XF1wuTkVFEd20kkGKtTw5VqcUmbcJViVSY7mbfotpH3g+lOgczLnBVZc0Ks3+jkm9ogFzT1n54vfbrBekBiYXgTW3ifJja9oH5SkYhrfg= Received: by 10.142.131.18 with SMTP id e18mr1331522wfd.147.1206027013269; Thu, 20 Mar 2008 08:30:13 -0700 (PDT) Received: from localhost.localdomain ( [71.229.200.170]) by mx.google.com with ESMTPS id 24sm3838331wfc.18.2008.03.20.08.30.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 20 Mar 2008 08:30:12 -0700 (PDT) Message-ID: <47E28302.8080608@roguewave.com> Date: Thu, 20 Mar 2008 09:30:10 -0600 From: Martin Sebor Organization: Rogue Wave Software, Inc. User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: _RWSTD_REQUIRES throwing uncaught exceptions in tests? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: Martin Sebor X-Virus-Checked: Checked by ClamAV on apache.org 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::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. >