From patchwork Thu Apr 10 11:53:48 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gary Benson X-Patchwork-Id: 472 Return-Path: X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx22.g.dreamhost.com (mx2.sub5.homie.mail.dreamhost.com [208.113.200.128]) by wilcox.dreamhost.com (Postfix) with ESMTP id A377336005B for ; Thu, 10 Apr 2014 04:53:56 -0700 (PDT) Received: by homiemail-mx22.g.dreamhost.com (Postfix, from userid 14314964) id 589CD527F63B; Thu, 10 Apr 2014 04:53:56 -0700 (PDT) X-Original-To: gdb@patchwork.siddhesh.in Delivered-To: x14314964@homiemail-mx22.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx22.g.dreamhost.com (Postfix) with ESMTPS id CEE065286C07 for ; Thu, 10 Apr 2014 04:53:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:mime-version :content-type; q=dns; s=default; b=cBa0xtSoAanBML6OgoHJH1y8l8u/i uiiFoOXHamPdK8bMKcXwopBSDsfUlAxyAxmppfL2Ig7egFWbZ1XpCxsSkTa0qd40 edByzXBRT+0Gm98FuXrOYCXEPhEBO+9rxg6/jmeRtkRADKWUJ2lT9M5vc4lX5ob9 FbdVWq674yVr/k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:subject:message-id:mime-version :content-type; s=default; bh=l/LiQTIPfqXa/pEVFvoxDvQW5Ks=; b=Ge/ n7Oy4tO0Yg2zmSDvGQJwosIMG+PUziGbRS2EN10E82gdavaeUWv/DVYMQDae4bP8 GkLK6UDJPLM1FHMh40bBlRbHj35SxFxE8gYcGfNk89vbUo+PHCRMQP2dbwPiSyqS ltOZbo81FI3uEiQeIMZ+0GSX/SFOrOrdFf9dHvlk= Received: (qmail 26596 invoked by alias); 10 Apr 2014 11:53:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 26586 invoked by uid 89); 10 Apr 2014 11:53:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 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; Thu, 10 Apr 2014 11:53:51 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3ABroVa022488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 10 Apr 2014 07:53:50 -0400 Received: from blade.nx (ovpn-116-84.ams2.redhat.com [10.36.116.84]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3ABrnhK006636 for ; Thu, 10 Apr 2014 07:53:49 -0400 Received: by blade.nx (Postfix, from userid 1000) id C1081263E55; Thu, 10 Apr 2014 12:53:48 +0100 (BST) Date: Thu, 10 Apr 2014 12:53:48 +0100 From: Gary Benson To: gdb-patches@sourceware.org Subject: [RFC][PATCH] Demangler crash resistance Message-ID: <20140410115348.GA1381@blade.nx> MIME-Version: 1.0 Content-Disposition: inline X-IsSubscribed: yes X-DH-Original-To: gdb@patchwork.siddhesh.in Hi all, A number of demangler crashes got filed recently, at least some of which are likely my fault. These need fixing, of course, but this highlighted to me the fact that GDB is probably the most sensitive user of libiberty's demangler in terms of crashes, etc. GCC and glibc only enter the demangler for error conditions, whereas GDB demangles symbols in general use. Furthermore, a given GDB session will likely demangle a lot of symbols. On the other side of the coin, I don't think many GDB hackers have the depth of knowledge to fix some of the more complicated crashes, in terms of understanding what the demangler is supposed to be producing. Feel free to correct me here (but be prepared for some questions if you do!) Here is a quandry where the people with the expertise to fix demangler crashes chiefly work on projects where such bugs are low priority. They're high priority for GDB, but we don't have the expertise to fix them. While the bugs are unfixed, our users may not be able to use GDB to debug their applications. I started to think maybe we should make GDB more resistant to demangler crashes, to keep our users in business. I attached a basic patch I've worked on as a proof of concept. I'm aware this needs portability work, a ChangeLog, and maybe error message throttling. More importantly, I'm also aware that none of the wrapped code uses cleanups, so caught failures will leak memory. Normally I wouldn't consider this appropriate, but I think here the benefit may outweigh the problems. Example sessions with the attached patch applied, using the symbol from https://sourceware.org/bugzilla/show_bug.cgi?id=16817: | (gdb) set lang c++ | (gdb) maint demangle _QueueNotification_QueueController__$4PPPPPPPM_A_INotice___Z | warning: internal error: demangler failed with signal 11 | Can't demangle "_QueueNotification_QueueController__$4PPPPPPPM_A_INotice___Z" and: | (gdb) add-symbol-file /home/gary/a.out 0 | add symbol table from file "/home/gary/a.out" at | .text_addr = 0x0 | (y or n) y | Reading symbols from /home/gary/a.out...warning: internal error: demangler failed with signal 11 | (no debugging symbols found)...done. Comments please :) Thanks, Gary diff --git a/gdb/cp-support.c b/gdb/cp-support.c index 2379b54..1783dd1 100644 --- a/gdb/cp-support.c +++ b/gdb/cp-support.c @@ -35,8 +35,8 @@ #include "expression.h" #include "value.h" #include "cp-abi.h" - #include "safe-ctype.h" +#include #define d_left(dc) (dc)->u.s_binary.left #define d_right(dc) (dc)->u.s_binary.right @@ -1482,12 +1482,40 @@ cp_lookup_rtti_type (const char *name, struct block *block) return rtti_type; } +/* Signal handler for gdb_demangle. */ + +static void +demangle_signal_handler (int signo) +{ + throw_error (GENERIC_ERROR, _("demangler failed with signal %d"), + signo); +} + /* A wrapper for bfd_demangle. */ char * gdb_demangle (const char *name, int options) { - return bfd_demangle (NULL, name, options); + volatile struct gdb_exception except; + void (*ofunc) (); + char *result = NULL; + + ofunc = (void (*)()) signal (SIGSEGV, demangle_signal_handler); + + TRY_CATCH (except, RETURN_MASK_ALL) + { + result = bfd_demangle (NULL, name, options); + } + + signal (SIGSEGV, ofunc); + + if (except.reason < 0) + { + warning ("internal error: %s", except.message); + result = NULL; + } + + return result; } /* Don't allow just "maintenance cplus". */