From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80796 invoked by alias); 30 Mar 2018 05:09:07 -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 80787 invoked by uid 89); 30 Mar 2018 05:09:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Mar 2018 05:09:04 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w2U58wna008074 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 30 Mar 2018 01:09:03 -0400 Received: by simark.ca (Postfix, from userid 112) id F3A1D1E77E; Fri, 30 Mar 2018 01:08:57 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 24DEB1E030; Fri, 30 Mar 2018 01:08:55 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 30 Mar 2018 05:09:00 -0000 From: Simon Marchi To: Weimin Pan Cc: gdb-patches@sourceware.org Subject: Re: [PATCH5 PR gdb/16959] gdb hangs in infinite recursion In-Reply-To: <1522269884-129860-1-git-send-email-weimin.pan@oracle.com> References: <1522269884-129860-1-git-send-email-weimin.pan@oracle.com> Message-ID: <20cf4b23322670e4dc513183ef2dda45@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 30 Mar 2018 05:08:58 +0000 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00603.txt.bz2 On 2018-03-28 16:44, Weimin Pan wrote: > The original problem was fixed (see related PR 22242). But using a > typedef > as the declared type for a static member variable, as commented in this > PR, > is still causing gdb to get into infinite loop when printing the static > member's value. This problem can be reproduced as follows: > > % cat t.cc > class A { > typedef A type; > public: > bool operator==(const type& other) { return true; } > > static const type INSTANCE; > }; > > const A A::INSTANCE; > > int main() { > A a; > if (a == A::INSTANCE) { > return -1; > } > return 0; > } > % g++ -g t.cc > % gdb -ex "start" -ex "p a" a.out > > The fix is rather trivial - in cp_print_static_field(), should call > check_typedef() to get the static member's real type and use it to > check whether it's a struct or an array. > > As Simon suggested, I've added a new test case to the testsuite > and am passing the original type, not the real type, as argument > to both cp_print_value_fields() and val_print(). > > Re-tested on both aarch64-linux-gnu and amd64-linux-gnu. No > regressions. Hi Weimin, Could you change the title to something more descriptive about what the change/fix is, rather than the problem being fixed? For example, "Fix infinite recursion when printing static member with typedef". It is ok to push with that fixed (feel free to ask if you still need some guidance). Thanks! Simon