From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8765 invoked by alias); 20 May 2014 19:36:01 -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 8755 invoked by uid 89); 20 May 2014 19:36:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 May 2014 19:36:00 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4KJZuet025904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 May 2014 15:35:57 -0400 Received: from barimba (ovpn-113-182.phx2.redhat.com [10.3.113.182]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s4KJZtcr024173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 May 2014 15:35:56 -0400 From: Tom Tromey To: Stan Shebs Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 0/2] Demangler crash handler References: <20140509100656.GA4760@blade.nx> <201405091120.s49BKO1f010622@glazunov.sibelius.xs4all.nl> <87fvkhjqvs.fsf@mid.deneb.enyo.de> <53737737.2030901@redhat.com> <87ppj8s7my.fsf@fleche.redhat.com> <537BA194.904@earthlink.net> Date: Tue, 20 May 2014 19:36:00 -0000 In-Reply-To: <537BA194.904@earthlink.net> (Stan Shebs's message of "Tue, 20 May 2014 11:40:20 -0700") Message-ID: <87tx8kqm3o.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-05/txt/msg00442.txt.bz2 Stan> So it's a little strange to me that it's now become so troublesome Stan> that it needs to be wrapped, or has been suggested, to be run in a Stan> different process(!), and it reinforces Mark K's original point Stan> about signal catchers masking more serious problems. The typical failure mode here is that gdb crashes when you start it. You cannot debug your program, and there is no reasonable workaround. (There is an unreasonable one: edit your binary to remove all mentions of the offending symbol.) What problem might be masked that is more serious than this? Stan> Complicated or not, the demangler is one of the most algorithmically Stan> predictable components of GDB, and it is very easy to test Stan> comprehensively; no races, no arcane target dependencies, textual Stan> input and output. So if it's becoming unreliable, perhaps there are Stan> process flaws that we should be addressing. I agree, that would be a good thing to do. However, even if the process flaws are fixed, it remains that gdb is unusually exposed to demangler bugs, and that the patch in question is not likely to cause harm. We know this because this technique is commonplace in the managed runtime community. And, supposing that the demangler is thoroughly de-bugged -- the patch in question will still not cause any harm. That is, addressing the process is not exclusive with this patch. I realize there is an attractive quality to the "suffering is good for us" idea. It appeals to my inner spartan. However, I disagree very strongly with this. As a thought experiment, consider applying this same logic to internal_error. The same considerations apply to making it simply abort. Yet, it would be a mistake to make this change -- because in the end, a user's debug session is more important than any particular gdb bug. BTW you can try it out thanks to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61233 Compile this with g++ and try it with a recent gdb. extern "C" void _Z7ZipWithI7QStringS0_5QListZN4oral6detail16AdaptCreateTableI7AccountEES0_RKNS3_16CachedFieldsDataEEUlRKS0_SA_E_ET1_IDTclfp1_cvT__EcvT0__EEEERKT1_ISC_ERKT1_ISD_ET2_ () { } int main() { return 0; } Ouch: barimba. ./gdb/gdb --quiet /tmp/q Reading symbols from /tmp/q...Segmentation fault (core dumped) Tom