From dev-return-24188-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Sun May 22 21:09:51 2011 Return-Path: X-Original-To: apmail-apr-dev-archive@www.apache.org Delivered-To: apmail-apr-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D041C6F2E for ; Sun, 22 May 2011 21:09:51 +0000 (UTC) Received: (qmail 18688 invoked by uid 500); 22 May 2011 21:09:51 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 18629 invoked by uid 500); 22 May 2011 21:09:51 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 18619 invoked by uid 99); 22 May 2011 21:09:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 May 2011 21:09:51 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of trawick@gmail.com designates 209.85.214.50 as permitted sender) Received: from [209.85.214.50] (HELO mail-bw0-f50.google.com) (209.85.214.50) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 May 2011 21:09:45 +0000 Received: by bwz2 with SMTP id 2so5374972bwz.37 for ; Sun, 22 May 2011 14:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3drW/eg9HMj3H6nCvBKfCy6MNN9c8vSrK/IcY5J5Aio=; b=X3wo0jVLaXSmb20a+dYE56PfQREUT1AYhAq0ixjVq1gTghpQf/EiP+BDoumn00Ke60 ZhN889T24t8SQr11lsINdvhaRt3oYM9CqxdtyQJz3uVF/j06FVhdf+xCMxdb0vs3CSkS norsbYv4EZgUkmKN3DoijCLg4n0DZ2Ss8HqRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=JUQQwa+hrBqZAH+qoKWeJWdVh1z0Pwu1VoPEKmdGb3JfhvNOF05slRrbPBwBIjQEw3 THz2ueLlBr1N7B/IaCpruO3qIVgFxO7469nyHy3AyJtWvhQ81ilXkaQOphzI2v+7FpvV MeQ0a3VNXmCqMeQ4rxHAeeA93wrsIxqrheoSc= MIME-Version: 1.0 Received: by 10.204.231.198 with SMTP id jr6mr1395579bkb.205.1306098564634; Sun, 22 May 2011 14:09:24 -0700 (PDT) Received: by 10.204.59.212 with HTTP; Sun, 22 May 2011 14:09:24 -0700 (PDT) In-Reply-To: <201105222242.37454.sf@sfritsch.de> References: <20110522201043.0F077238896F@eris.apache.org> <201105222242.37454.sf@sfritsch.de> Date: Sun, 22 May 2011 17:09:24 -0400 Message-ID: Subject: Re: testreslist failures / thread-safety issues From: Jeff Trawick To: dev@apr.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org On Sun, May 22, 2011 at 4:42 PM, Stefan Fritsch wrote: > On Sunday 22 May 2011, sf@apache.org wrote: >> Author: sf >> Date: Sun May 22 20:10:42 2011 >> New Revision: 1126207 >> >> URL: http://svn.apache.org/viewvc?rev=1126207&view=rev >> Log: >> Fix thread unsafe pool usage. This is a potential culprit for the >> occasional testreslist failures. > > Can those people who frequently hit the testreslist failures please > check if this commit helps? From a powerpc Debian build host, it looks > promising, but I don't have direct access to that machine and can't do > repeated tests there. no luck on Windows 7 apr-util 1.3.x, gcc, still fails apr trunk, Visual C++ 2008 Express, still fails Seven:~/svn/apr-util-1.3.x-xx/test$ ./testall -v testreslist testreslist : /Line 258: expected <10>, but saw <20> FAILED 1 of 1 Failed Tests Total Fail Failed % =================================================== testreslist 1 1 100.00% > > Unfortunately, there are also other thread-safety issues in apr/apr- > util. Using hellgrind on testreslist found these issues: > > - unsafe read of pool->child in apr_pool_destroy. This one worries me. > If a subpool is destroyed in one thread while the pool itself is > destroyed in another thread, it can happen that apr_pool_destroy is > called again for the subpool. This would likely lead to a crash. > Any ideas on how to fix this without sacrificing too much performance? > > - unsafe read of allocator->max_index (PR 48535, likely not critical) > > - unsafe read of _myself->thd_cnt in thread_pool_cleanup() (likely not > critical; but there seem to be other thread-safety issues in that > file, at least the access of thd_high is also unsafe) > > > Cheers, > Stefan > -- Born in Roswell... married an alien...