From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126699 invoked by alias); 2 Jan 2016 02:18:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 126688 invoked by uid 89); 2 Jan 2016 02:18:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=HTo:U*palves, staring, leader X-HELO: mail-lf0-f42.google.com Received: from mail-lf0-f42.google.com (HELO mail-lf0-f42.google.com) (209.85.215.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 02 Jan 2016 02:18:36 +0000 Received: by mail-lf0-f42.google.com with SMTP id c192so76262275lfe.2 for ; Fri, 01 Jan 2016 18:18:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.25.205.76 with SMTP id d73mr15873185lfg.76.1451701112751; Fri, 01 Jan 2016 18:18:32 -0800 (PST) Received: by 10.25.21.220 with HTTP; Fri, 1 Jan 2016 18:18:32 -0800 (PST) In-Reply-To: <56844E1B.20507@redhat.com> References: <566FFEE2.4010300@samsung.com> <56823702.6020804@samsung.com> <5682C264.3030109@redhat.com> <5682CC66.70608@samsung.com> <56844BE3.9030508@redhat.com> <56844E1B.20507@redhat.com> Date: Sat, 02 Jan 2016 02:18:00 -0000 Message-ID: Subject: Re: [PATCH][PING][PR gdb/19361] Fix invalid comparison functions From: Yuri Gribov To: Pedro Alves Cc: Yury Gribov , gdb-patches@sourceware.org, Stan Shebs , Paul Pluzhnikov Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-01/txt/msg00010.txt.bz2 On Thu, Dec 31, 2015 at 12:35 AM, Pedro Alves wrote: > On 12/30/2015 09:25 PM, Pedro Alves wrote: >> On 12/30/2015 08:18 PM, Yuri Gribov wrote: >> >>> Sorry, I should have been more wordy about the actual problem. With >>> current approach i.e. >>> >>> if (pid1 == pgid1) >>> return -1; >>> else if (pid2 == pgid2) >>> return 1; >>> >>> comparison of two group leaders is not going to be symmetric: >>> >>> cmp(lead_1, lead_2) == cmp(lead_2, lead_1) == -1 >> >> Aaaaaaah, d'oh! Thanks, it's obvious now, yes, we fail to consider >> the case of both elements being leaders. I couldn't see that >> even after staring at the code for a while. That hunk is OK as >> is then. (Please clarify this in the commit log.) > > Wait, no we don't... If both are leaders when you get there, then > they must have different pgid's, and that case is handled before: > > /* Sort by PGID. */ > if (pgid1 < pgid2) > return -1; > else if (pgid1 > pgid2) > return 1; > else > > But let's assume not. Let's assume we see two leaders when you get to the > code in question. That means they have pgid1==pgid2. Since by definition > being leader means pgid==pid, it must be that pid1 == pid2 as well. That > is, this is really about comparing equivalent elements. Which > brings us back again to: > > /* Easier to check for equivalent element first. */ > if (pid1 == pid2) > return 0; > > Or am I confused again? Hm, this sounds reasonable. Let me see if I can repro this bug and get the exact inputs which caused the problem (unfortunately I didn't collect them during testing). -Y