From stdcxx-dev-return-3534-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Tue May 29 19:57:21 2007 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 98120 invoked from network); 29 May 2007 19:57:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 May 2007 19:57:21 -0000 Received: (qmail 28021 invoked by uid 500); 29 May 2007 19:57:25 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 28010 invoked by uid 500); 29 May 2007 19:57:25 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 27999 invoked by uid 99); 29 May 2007 19:57:25 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2007 12:57:25 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 May 2007 12:57:20 -0700 Received: from qxvcexch01.ad.quovadx.com ([192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.6) with ESMTP id l4TJuNF7022728 for ; Tue, 29 May 2007 19:56:23 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 May 2007 13:56:22 -0600 Message-ID: <465C85E2.6070402@roguewave.com> Date: Tue, 29 May 2007 13:58:26 -0600 From: Martin Sebor Organization: Rogue Wave Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070221 SeaMonkey/1.1.1 MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: Intel Thread Checker Support References: <465118A9.30407@roguewave.com> <0B39DB22-C426-48B3-AAA2-560AF5F4FE70@roguewave.com> <46522879.6090409@roguewave.com> <4B2DED28-7166-4FB8-825A-DDC9978EB505@roguewave.com> <465C52AC.4050601@roguewave.com> <465C6C67.70100@roguewave.com> In-Reply-To: <465C6C67.70100@roguewave.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 May 2007 19:56:23.0007 (UTC) FILETIME=[6ED49EF0:01C7A22B] X-Virus-Checked: Checked by ClamAV on apache.org Liviu Nicoara wrote: > Liviu Nicoara wrote: >> Liviu Nicoara wrote: >>> On May 21, 2007, at 7:17 PM, Martin Sebor wrote: >>> >>>> Liviu Nicoara wrote: >>>>> I agree it would be a spectacular demonstration of the usefulness >>>>> of the tool but -- based on my knowledge of the stdcxx code -- I >>>>> strongly doubt I can demonstrate an MT bug in it. Do you know of an >>>>> unresolved MT bug in stdcxx? >>>> >>>> There is a problem in locale (as usual, sigh :( A couple of our >>>> thread safety tests have been crashing: 22_mt and 22_time_put_mt. >> >> I see they are not ported to the new infrastructure yet. Are they >> failing in dev or latest release? One [looong] run of 22_mt yielded no >> failures. > > FWIW, the run of the 4.1.4-rel branch of locale/mt.cpp (in a 15s build > on Linux Slackware 10.2 on x86, with Intel 9.1.042) has yielded the > analysis in the attached file. I have chosen the text format and a width > of 140 columns for readability. Please notice that the run has not > failed any [test] assertions. > > I am not sure what to make about the errors flagged by the ITC tool > because I am not sufficiently familiar with the locale code. A quick > glance over the places in the analysis report shows unguarded rw > accesses to certain memory locations (used to store facets?). I am not > sure though whether this access is intentionally unguarded or not. They do look unguarded but I don't think I would describe them as bugs given the "loose" rules for thread safety we follow in stdcxx (we make assumptions about ordering and visibility that aren't guaranteed to hold in general but typically do in our experience). OTOH, for something as involved and as "lightly" used as locale we should probably err on the side of safety and avoid making them altogether. Certainly, we would need to clean up (or silence) all these errors in order for the the Thread Checker reports to be useful to stdcxx users. Otherwise they wouldn't be able to reliably tell whether the errors represent potential thread safety issues in their programs or not even after they cleaned up all errors coming out of their own code. I think this cleanup would be useful for us to do but the hard part will be running the Thread Checker on all our thread safety tests and analyzing the results. And since we don't even have tests for all our thread-safety sensitive code we'd also need to add some. They wouldn't be too difficult to write. I'd say we should be able to add tests for all of locale in a week, and then take another week to clean up all the errors. Martin