From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119172 invoked by alias); 19 May 2015 12:35: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 119160 invoked by uid 89); 19 May 2015 12:35:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 19 May 2015 12:35:41 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 146078EA53; Tue, 19 May 2015 12:35:40 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-27.ams2.redhat.com [10.36.116.27]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4JCZaNQ018164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 May 2015 08:35:39 -0400 Date: Tue, 19 May 2015 12:35:00 -0000 From: Jan Kratochvil To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: [patch] Fix ASAN crash for gdb.compile/compile.exp Message-ID: <20150519123536.GA27983@host1.jankratochvil.net> References: <20150418170138.GA9123@host1.jankratochvil.net> <867fs4ssb6.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867fs4ssb6.fsf@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00476.txt.bz2 On Tue, 19 May 2015 13:46:53 +0200, Yao Qi wrote: > Jan Kratochvil writes: > > Whether the objfile really should be already freed during > > call_function_by_hand_dummy() I am not sure. > > Is there any reason we release OBJFILE in the dummy frame dtor? Why > don't we register a cleanup to release in OBJFILE in compile_object_run? > together with releasing compile_module? 'struct compile_module' has a > field objfile, which should be released together with > 'struct compile_module' instead of dummy_frame. (gdb) break puts Breakpoint 2 at 0x3830c6fd30: file ioputs.c, line 34. (gdb) compile code puts("hello") Breakpoint 2, _IO_puts (str=0x7ffff7ff8000 "hello") at ioputs.c:34 34 { The program being debugged stopped while in a function called from GDB. Evaluation of the expression containing the function (_gdb_expr) will be abandoned. When the function is done executing, GDB will silently stop. (gdb) bt #0 _IO_puts (str=0x7ffff7ff8000 "hello") at ioputs.c:34 #1 0x00007ffff7ff9183 in _gdb_expr (__regs=0x7ffff7ff7000) at gdb command line:1 #2 #3 main (argc=1, argv=0x7fffffffd7a8) at gdb.c:25 (gdb) _ Now compile_object_run() called from line (gdb) compile code puts("hello") has finished for a long time. But we still need to have that injected code OBJFILE valid when GDB is executing it. Therefore OBJFILE is freed only from destructor of the frame #1. At the patched line of call_function_by_hand_dummy() the dummy frame destructor has not yet been run but it will be run before the fetched NAME will get used. In fact I do not see now how to fix it differently than what the patch does. Obviously all these ugly hacks are needed only because GDB does not have convenient memory management like C++/Java/others. Jan