From stdcxx-dev-return-4297-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Sun Aug 12 21:39:36 2007 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 64295 invoked from network); 12 Aug 2007 21:39:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Aug 2007 21:39:36 -0000 Received: (qmail 56769 invoked by uid 500); 12 Aug 2007 21:39:34 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 56756 invoked by uid 500); 12 Aug 2007 21:39:34 -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 56734 invoked by uid 99); 12 Aug 2007 21:39:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Aug 2007 14:39:34 -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 209.85.198.185 as permitted sender) Received: from [209.85.198.185] (HELO rv-out-0910.google.com) (209.85.198.185) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 Aug 2007 21:39:31 +0000 Received: by rv-out-0910.google.com with SMTP id k20so1146579rvb for ; Sun, 12 Aug 2007 14:39:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; 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; b=JvhOWiKsl+EzuQz7pT+Uwyo6oP18RPBFeeVoU1ncSK8hWqw+CUAc/hVSTnplXFffLzOK0C2jTdaSdqYaIv9FwuUWBR7geoGSHMkZicVzFdGIWBsFEUijK8L+LsZnS3QVWozIpfATqH6jaHTu8L/t+Ltvpg4Yiw2LOhxT3hsdvu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=Rsx4dMCwEsvJGPcKeNZ8tfy+nZ6mahxKStPSBS+kOKDsyKCpEoFef3Js10kMa6Y4AmXcBrQdmDlPqKbWLwj6mHHZMyXl5BzuUp6umhaRuSa94M3KifaUZg08jCYf4aQwLDkmbauwDWTuDCba544vG0IjPaLStoQ2fuGz+Oq9roE= Received: by 10.141.5.3 with SMTP id h3mr2251446rvi.1186954750708; Sun, 12 Aug 2007 14:39:10 -0700 (PDT) Received: from ?192.168.1.104? ( [71.229.200.170]) by mx.google.com with ESMTPS id c14sm9993613rvf.2007.08.12.14.39.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Aug 2007 14:39:10 -0700 (PDT) Message-ID: <46BF7DFC.9040308@roguewave.com> Date: Sun, 12 Aug 2007 15:39:08 -0600 From: Martin Sebor Organization: Rogue Wave Software User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20070719 Fedora/1.0.9-2.fc6 pango-text SeaMonkey/1.0.9 MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: [PATCH] Update test 22.locale.num.put.mt.cpp to validate results References: <46B7A997.7000201@roguewave.com> <46BCCDA7.7050700@roguewave.com> 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 Travis Vitek wrote: > > >> -----Original Message----- >> From: Martin Sebor [mailto:sebor@roguewave.com] >> Sent: Friday, August 10, 2007 1:42 PM >> To: stdcxx-dev@incubator.apache.org >> Subject: Re: [PATCH] Update test 22.locale.num.put.mt.cpp to >> validate results >> >> Travis Vitek wrote: >> >>> >>> >>> Martin Sebor wrote: >>> >>>> We can't be using rw_assert() in a thread function (the driver >>>> isn't thread safe yet, and if it was it would unnecessarily >>>> synchronize the threads). Use the RW_ASSERT() macro instead. >>>> >>> >>> I think there will be a lot of useful context that is lost if >>> I switch to RW_ASSERT. It would be especially useful to know >>> the active locale, the input value, and the output values in >>> these test cases. >> These values are invaluable when the tests fail due to a problem >> other than a thread safety bug in the library but I'm not sure >> they would be of much use in the case of a thread safety bug >> that manifests itself by corrupting data. Do you have specific >> scenario in mind where this information would be useful? >> >> > > One example that I ran into in my limited testing was that a locale > was getting created with the correct name, but it was not the correct > locale that was getting used. The data wasn't corrupt, it was just > for the wrong locale. > > # INFO (S1) (3 lines): > # TEXT: testing std::time_put with 4 threads, 100000 iterations > each, in locales { "en_US" "es_MX" } > # CLAUSE: lib.locale.time.put > > # WARNING (S5) (3 lines): > # TEXT: locale="en_US" output="jue" expected="Thu" > # CLAUSE: lib.locale.time.put > > Sure this is a threading bug, but IMO the generated message is more > useful than the other option I agree that it looks more informative, but I'm not sure it really is. Could you reproduce this consistently from run to run? If not, it might be just a coincidence. In any event, I agree that if we can avoid the synchronization in the successful cases providing additional detail in the diagnostic messages can be helpful. But rather than complicating the test driver API with this detail I'd make the driver (i.e., calls to rw_assert() et al) thread-safe. It should be straightforward to do: simply add a global mutex to the driver and lock in on entry to each of these functions. > [...] > The other nice thing is that the test will continue, possibly exposing > additional problems. I don't think we should trust the test after the first failure. Also, since each thread function iterates thousands of times we might end up with tens of thousands of lines of output. I don't have a big problem with making this an option of the test just so long as it's disabled by default (for nightly builds). > [...] > Yes, that would be another workable solution. Honestly I'm hoping that > once these tests are up and running the bugs will be found and there > won't be any problems to speak of. If that is the case, then all of this > discussion is moot. Well, of course :) Once all the bugs have been fixed there will be no failures to report. But the value of the tests will not only be in helping us find and fix the existing bugs but also in helping us catch future regressions. Martin