From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27343 invoked by alias); 25 Feb 2010 19:49:45 -0000 Received: (qmail 27323 invoked by uid 22791); 25 Feb 2010 19:49:44 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 25 Feb 2010 19:49:40 +0000 Received: (qmail 13152 invoked from network); 25 Feb 2010 19:49:38 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Feb 2010 19:49:38 -0000 From: Pedro Alves To: Tom Tromey Subject: Re: RFC: fix bug with std::terminate handler Date: Thu, 25 Feb 2010 19:49:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic; KDE/4.3.2; x86_64; ; ) Cc: gdb-patches@sourceware.org References: <201002251826.46359.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002251949.36154.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2010-02/txt/msg00633.txt.bz2 On Thursday 25 February 2010 19:19:28, Tom Tromey wrote: > >>>>> "Pedro" == Pedro Alves writes: > > Tom> call_function_by_hand installs a momentary breakpoint on std::terminate, > Tom> and then deletes it later. However, this can cause a double deletion of > Tom> the breakpoint. In the bug, the called function is dlopen, which causes > Tom> gdb to enter solib_add, which calls breakpoint_re_set, deleting the > Tom> momentary breakpoint. > > Pedro> Why doesn't stepping over "dlopen", with "(gdb) next" cause the > Pedro> same problem with step-resume breakpoints? > > The step-resume breakpoints have type bp_step_resume, which are handled > specially by breakpoint_re_set_one. The std::terminate breakpoint is > just a plain bp_breakpoint. Yes, that's the problem. > I suppose I could add a new bptype, though that seems rather heavy for > this. No momentary breakpoint should have bp_breakpoint type. All that do will have the same problem. I see infcmd.c:finish_backward is also broken in the same way although finish_forward uses bp_finish. In fact, it's exactly this abuse of bp_breakpoint that let to the need of the make_breakpoint_silent call there... A `gdb_assert (type != bp_breakpoint)' in set_momentary_breakpoint would be a Nice To Have. There's also the option of making the breakpoint at std::terminate be a real internal breakpoint, enabled/disabled on need, a-la-E.g., enable_overlay_breakpoints or set_longjmp_breakpoint. The advantage is that if the dlopen causes the first load of libstdc++ ever in the binary (quite rare, but possible), the breakpoint at std::terminate resolves itself magically and you still catch a call to it. This option requires adding a breakpoint type as well. > If you have a particular approach you think would be best, I would be > happy to implement that. Thanks. Take your pick from the above. I also though of adding a flag to the breakpoint struct to tag it as momentary/temporary, but it feels hackish and a bit lazy given what I said above. :-) But I wouldn't say no to such fix. -- Pedro Alves