From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115239 invoked by alias); 22 May 2018 14:39:42 -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 115205 invoked by uid 89); 22 May 2018 14:39:41 -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,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 May 2018 14:39:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 70E27117B83; Tue, 22 May 2018 10:39:38 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OtYnpsB99Xlz; Tue, 22 May 2018 10:39:38 -0400 (EDT) Received: from tron.gnat.com (tron.gnat.com [205.232.38.10]) by rock.gnat.com (Postfix) with ESMTP id 4DF41117B81; Tue, 22 May 2018 10:39:38 -0400 (EDT) Received: by tron.gnat.com (Postfix, from userid 4233) id 4A24A4F3; Tue, 22 May 2018 10:39:38 -0400 (EDT) From: Joel Brobecker To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: [pushed+RFC] C++ exception during command triggers stale cleanup internal-warning Date: Tue, 22 May 2018 14:49:00 -0000 Message-Id: <1526999977-126638-1-git-send-email-brobecker@adacore.com> In-Reply-To: References: X-SW-Source: 2018-05/txt/msg00556.txt.bz2 Hello, There was a small bug in Tom's patch that caused the execution of the "catch assert" command to throw a C++ exception. I have pushed the following patch to master as an obvious fix to the immediate issue: [] fix "stale cleanup" internal-warning when using "catch assert" But at the same time, this leads me to believe we may have a weakness top.c::execute_command, which installs a cleanup, and "forgets" to discard it when C++ exceptions are raised. But maybe that's just the way it is, and we just want to make sure we never let C+ exceptions get away from us? Thoughts on that? Anyways, for now, the immediate issue is fixed. -- Joel