From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11613 invoked by alias); 9 Jun 2014 15:22:44 -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 11597 invoked by uid 89); 9 Jun 2014 15:22:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 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; Mon, 09 Jun 2014 15:22:42 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s59FMbUF020237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 9 Jun 2014 11:22:37 -0400 Received: from blade.nx (ovpn-116-92.ams2.redhat.com [10.36.116.92]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s59FMU7w003020; Mon, 9 Jun 2014 11:22:31 -0400 Received: by blade.nx (Postfix, from userid 1000) id CC41E26243B; Mon, 9 Jun 2014 16:22:29 +0100 (BST) Date: Mon, 09 Jun 2014 15:22:00 -0000 From: Gary Benson To: gdb-patches@sourceware.org Cc: Andrew Burgess , Doug Evans , Eli Zaretskii , Florian Weimer , Mark Kettenis , Pedro Alves , Tom Tromey Subject: [PATCH 0/3 v5] Demangler crash handler Message-ID: <20140609152229.GA27494@blade.nx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00384.txt.bz2 Hi all, This series is an updated version of the demangler crash handler I posted last week. The main changes are: 1) check_can_dump_core has been renamed back to the can_dump_core, and I renamed check_can_dump_core_warn as can_dump_core_warn as per https://sourceware.org/ml/gdb-patches/2014-06/msg00307.html. 2) can_dump_core and can_dump_core_warn have a new parameter, limit_kind, to specify which limit to check. The original calls in internal_vproblem use the hard limit, and the calls from the crash catcher that this series adds use the soft limit. 3) The crash catcher prints "Attempting to dump core" to alert the user that a core file might have been created. The patches are split as before: 1/3 - adds a new category of internal problem for demangler warnings. This patch is unchanged from the previous two versions (PATCH 1/2 v3 and v4). https://sourceware.org/ml/gdb-patches/2014-06/msg00142.html https://sourceware.org/ml/gdb-patches/2014-06/msg00252.html 2/3 - refactors and exposes the core-dumping functions in utils.c. This patch differs from the previous version as described in points 1 and 2 in the above list. 3/3 - the crash catcher itself. This patch differs from the previous version as described in points 2 and 3 in the above list. I would push all three patches as one commit. The news file entries for the commit would be: * New options maint set catch-demangler-crashes (on|off) maint show catch-demangler-crashes Control whether GDB should attempt to catch crashes in the symbol name demangler. maint set demangler-warning quit (yes|no|ask) maint show demangler-warning quit Control whether GDB should exit if it catches a crash in the symbol name demangler. * New commands maint demangler-warning Cause GDB to call the internal function demangler_warning and hence behave as though an internal error in the demangler has been detected. Is this ok to commit? Thanks, Gary -- http://gbenson.net/