From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28689 invoked by alias); 23 Apr 2014 17:04:21 -0000 Mailing-List: contact overseers-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: , Sender: overseers-owner@sourceware.org Received: (qmail 28636 invoked by uid 89); 23 Apr 2014 17:04:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: qmta14.emeryville.ca.mail.comcast.net Received: from qmta14.emeryville.ca.mail.comcast.net (HELO qmta14.emeryville.ca.mail.comcast.net) (76.96.27.212) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Apr 2014 17:04:19 +0000 Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta14.emeryville.ca.mail.comcast.net with comcast id tV1m1n0041Y3wxoAEV4Jso; Wed, 23 Apr 2014 17:04:18 +0000 Received: from up.mrs.kithrup.com ([24.4.193.248]) by omta15.emeryville.ca.mail.comcast.net with comcast id tV4G1n00w5N1HX48bV4H4X; Wed, 23 Apr 2014 17:04:17 +0000 Content-Type: multipart/mixed; boundary="Apple-Mail=_9E067875-24CE-4DEA-B25C-4E98FF7139E0" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: ezmlm warning From: Mike Stump In-Reply-To: <20140423154314.GB26579@elastic.org> Date: Wed, 23 Apr 2014 17:04:00 -0000 Cc: "overseers@gcc.gnu.org" Message-Id: References: <1398055301.29540.ezmlm-warn@gcc.gnu.org> <656956BA-3E9D-4867-BD86-B30F3EEADA7A@comcast.net> <20140423154314.GB26579@elastic.org> To: "Frank Ch. Eigler" X-SW-Source: 2014-q2/txt/msg00010.txt.bz2 --Apple-Mail=_9E067875-24CE-4DEA-B25C-4E98FF7139E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Content-length: 698 On Apr 23, 2014, at 8:43 AM, Frank Ch. Eigler wrote: >> I=92ve checked lots of my old email for dkim=3Dfail, and I see all >> bugzilla email fails dkim. The latest failure was on March 31, >> 2014. >=20 > It'd be handy if you could find a couple of raw message URLs in the > archives for analysis. Here are the raw bits for the last one I saw. I think you can reproduce it= on demand by cc: yourself on a bug report, and then just modify it. It wi= ll then send out email to you. The advantage of doing that is you can then get logging from the various to= ols and see in depth what was going on. I=92ll discount the issue I saw as a foible on comcast=92s part. Thanks. --Apple-Mail=_9E067875-24CE-4DEA-B25C-4E98FF7139E0 Content-Disposition: attachment; filename=59305.eml.bin Content-Type: application/macbinary; name="59305.eml.bin" Content-Transfer-Encoding: quoted-printable Content-length: 6334 Return-Path: gcc-bugzilla@gcc.gnu.org=0D=0A= Received: from imta17.emeryville.ca.mail.comcast.net (LHLO=0D=0A= imta17.emeryville.ca.mail.comcast.net) (76.96.30.78) by=0D=0A= sz0012.ev.mail.comcast.net with LMTP; Mon, 31 Mar 2014 09:55:33 +0000 (UTC= )=0D=0A= Received: from sourceware.org ([209.132.180.131])=0D=0A= by imta17.emeryville.ca.mail.comcast.net with comcast=0D=0A= id k9vZ1n0192qVqVd0H9vZTf; Mon, 31 Mar 2014 09:55:33 +0000=0D=0A= X-CAA-SPAM: N00000=0D=0A= X-Authority-Analysis: v=3D2.1 cv=3Dcbzr8BzM c=3D1 sm=3D1 tr=3D0=0D=0A= a=3DvbYRN7G9ZuyAWxq09MFwFw=3D=3D:117 a=3DvbYRN7G9ZuyAWxq09MFwFw=3D=3D:17 a= =3DCCpqsmhAAAAA:8=0D=0A= a=3DC_IRinGWAAAA:8 a=3DGGcpBh7Jt_oA:10 a=3DUi9JsjPGqVgA:10 a=3DToTwbZcZLiU= A:10=0D=0A= a=3DIkcTkHD0fZMA:10 a=3DmDV3o1hIAAAA:8 a=3DfML7m_gIA7JJtxXS9jEA:9 a=3DQEXd= DO2ut3YA:10=0D=0A= a=3D2fcrIxHVTVsA:10=0D=0A= Authentication-Results: imta17.emeryville.ca.mail.comcast.net;=0D=0A= dkim=3Dfail (signature hash does not match body) header.d=3Dgcc.gnu.org he= ader.b=3DlZNyECRE=0D=0A= DomainKey-Signature: a=3Drsa-sha1; c=3Dnofws; d=3Dgcc.gnu.org; h=3Dfrom:to= =0D=0A= :subject:date:message-id:in-reply-to:references:content-type=0D=0A= :content-transfer-encoding:mime-version; q=3Ddns; s=3Ddefault; b=3DTXb=0D= =0A= rQx2IWMwHNXWGru7YpQXqh6Dycc/h63fV/tetfLYqfeOqggt4ENha9Hnfkii7Dkn=0D=0A= iNC9F3yL2HhlzinPZBwwHHDWaxNOQsXOf8n+M4OOYcZfvXCCJUT0lYtOoVDP160t=0D=0A= Eg5aLy02DO4huBREYZ1AbVgVQvnL7hUzNWs5ovxU=3D=0D=0A= DKIM-Signature: v=3D1; a=3Drsa-sha1; c=3Drelaxed; d=3Dgcc.gnu.org; h=3Dfrom= :to=0D=0A= :subject:date:message-id:in-reply-to:references:content-type=0D=0A= :content-transfer-encoding:mime-version; s=3Ddefault; bh=3DIXMiMkaSW=0D=0A= R3bKVskYsuSxXgM8ZQ=3D; b=3DlZNyECRED8xkEoEyiluO5FgZKBsWYhkmcW+PKCwqT=0D=0A= KFfu3LxybDhwq0o4etQNUPEtpU1CGv3RdwtB4wg9hKSoSEQ4JWSM/yoyE6gACfZm=0D=0A= /fAlPS2HAKkyPmo4Mhc3NAq6Jg2VzYYR9VGcc7bbuSHk3A8Ug1AgqYQf8S7nlMBV=0D=0A= Bo=3D=0D=0A= Received: (qmail 20263 invoked by uid 48); 31 Mar 2014 09:55:32 -0000=0D=0A= From: "iains at gcc dot gnu.org" =0D=0A= To: mikestump@comcast.net=0D=0A= Subject: [Bug target/59305] [4.9 Regression]=0D=0A= gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on= =0D=0A= x86_64-apple-darwin13=0D=0A= Date: Mon, 31 Mar 2014 09:55:29 +0000=0D=0A= X-Bugzilla-Reason: CC=0D=0A= X-Bugzilla-Type: changed=0D=0A= X-Bugzilla-Watch-Reason: None=0D=0A= X-Bugzilla-Product: gcc=0D=0A= X-Bugzilla-Component: target=0D=0A= X-Bugzilla-Version: 4.9.0=0D=0A= X-Bugzilla-Keywords: =0D=0A= X-Bugzilla-Severity: normal=0D=0A= X-Bugzilla-Who: iains at gcc dot gnu.org=0D=0A= X-Bugzilla-Status: NEW=0D=0A= X-Bugzilla-Priority: P1=0D=0A= X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org=0D=0A= X-Bugzilla-Target-Milestone: 4.9.0=0D=0A= X-Bugzilla-Flags:=0D=0A= X-Bugzilla-Changed-Fields: =0D=0A= Message-ID: =0D=0A= In-Reply-To: =0D=0A= References: =0D=0A= Content-Type: text/plain; charset=3D"UTF-8"=0D=0A= Content-Transfer-Encoding: quoted-printable=0D=0A= X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/=0D=0A= Auto-Submitted: auto-generated=0D=0A= MIME-Version: 1.0=0D=0A= =0D=0A= http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D3D59305=0D=0A= =0D=0A= =0D=0A= =0D=0A= --- Comment #19 from Iain Sandoe ---=0D=0A= =0D=0A= (In reply to Richard Biener from comment #18)=0D=0A= =0D=0A= > sparc-sun-solaris2.10 is a primary arch, making P1 for now. As sparc=0D= =0A= =0D=0A= > implements=0D=0A= =0D=0A= > the hook Joseph mentions is this merely a testsuite issue (sparc being=0D= =0A= =0D=0A= > "slow")?=0D=0A= =0D=0A= =0D=0A= =0D=0A= In Darwin's case, I don't believe it is (simply) a test-suite issue;=0D=0A= =0D=0A= =0D=0A= =0D=0A= Rather it is connected with the implementation of pthread-based locking in= =0D=0A= =0D=0A= libatomic when entities larger than those natively-supported are used.=0D= =0A= =0D=0A= =0D=0A= =0D=0A= So, for example, if libatomic is configured to use a machine supporting=0D= =0A= =0D=0A= cmpxchg16b, then test-time drops from 50mins -> 1min (c.f. configuring with= =3D=0D=0A= =0D=0A= out=0D=0A= =0D=0A= cmpxchg16b).=0D=0A= =0D=0A= =0D=0A= =0D=0A= Probing the stalled cases, shows that things are stuck in mutex code.=0D=0A= =0D=0A= =0D=0A= =0D=0A= I started looking at the (default) posix implementation of the locking in= =0D=0A= =0D=0A= libatomic (partly to see if there was a more BSD-esque way to do it). Howe= =3D=0D=0A= =0D=0A= ver,=0D=0A= =0D=0A= I'm out of time for the next couple of weeks.=0D=0A= =0D=0A= =0D=0A= =0D=0A= Two things (in the posix libatomic implementation) that might bear more=0D= =0A= =0D=0A= examination:=0D=0A= =0D=0A= =0D=0A= =0D=0A= 1) adjacent entities that happen to fall within one cache line size (which= =0D=0A= =0D=0A= would apply to two 32byte numbers stored consecutively, for x86) get the sa= =3D=0D=0A= =0D=0A= me=0D=0A= =0D=0A= hash ID. I wonder if that can introduce a vulnerability.=0D=0A= =0D=0A= =0D=0A= =0D=0A= 2) If the alignment of an entity is < its size, AFAICT the entity could spa= n=0D=0A= =0D=0A= two hash IDs without this being detected [the evaluation is carried out mod= =3D=0D=0A= =0D=0A= ulo=0D=0A= =0D=0A= size without considering alignment].=0D=0A= =0D=0A= =0D=0A= =0D=0A= =3D3D=3D3D=3D3D=0D=0A= =0D=0A= =0D=0A= =0D=0A= On darwin it's possible to resolve the issue by replacing the=0D=0A= =0D=0A= pthread_mutex_lock()s with=0D=0A= =0D=0A= while ((err =3D3D pthead_mutex_trylock(=3DE2=3D80=3DA6)) !=3D3D 0)=0D=0A= =0D=0A= if (err =3D3D=3D3D =3DE2=3D80=3DA6) abort();=0D=0A= =0D=0A= =0D=0A= =0D=0A= .. which might indicate an underlying issue with the implementation of pthr= =3D=0D=0A= =0D=0A= eads=0D=0A= =0D=0A= (or it might simply modify the behaviour enough to cause some other=0D=0A= =0D=0A= vulnerability to be hidden).=0D=0A= =0D=0A= =0D=0A= =0D=0A= --=0D=0A= =0D=0A= =0D=0A= =0D=0A= I don't know if the same approach (spinning on try lock) would resolve the= =0D=0A= =0D=0A= issue on Solaris, or (particularly) how to interpret the findings yet.=0D= =0A= =0D=0A= =0D=0A= =0D=0A= --=3D20=0D=0A= =0D=0A= You are receiving this mail because:=0D=0A= =0D=0A= You are on the CC list for the bug.=3D=0D=0A= =0D=0A= --Apple-Mail=_9E067875-24CE-4DEA-B25C-4E98FF7139E0--