Message ID | 53271C09.5000709@mentor.com |
---|---|
State | Superseded |
Headers |
Return-Path: <x14314964@homiemail-mx21.g.dreamhost.com> X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx21.g.dreamhost.com (caibbdcaaahb.dreamhost.com [208.113.200.71]) by wilcox.dreamhost.com (Postfix) with ESMTP id B4F5A3600D3 for <siddhesh@wilcox.dreamhost.com>; Mon, 17 Mar 2014 09:00:21 -0700 (PDT) Received: by homiemail-mx21.g.dreamhost.com (Postfix, from userid 14314964) id 6D7EEC53595; Mon, 17 Mar 2014 09:00:21 -0700 (PDT) X-Original-To: gdb@patchwork.siddhesh.in Delivered-To: x14314964@homiemail-mx21.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-mx21.g.dreamhost.com (Postfix) with ESMTPS id 3A1C52135A9E for <gdb@patchwork.siddhesh.in>; Mon, 17 Mar 2014 09:00:21 -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:message-id:date:from:mime-version:to:subject :content-type:content-transfer-encoding; q=dns; s=default; b=GbL npNWxnv/o8FZwhYcQHeOjo/SyRZ2M5Kn7DJucqUNR7wm62QhfqmPrZZ/eSZdpJTT 3LZAEcLZJfL3hfGbQo9jc6HfQxAcv6jCmnQmfirzaUO1zTTsAukJnE9lIVnLe6NO Svbex7eppgw4TN+qsEsM4oY2iQHE2fyQHbJ+FRGo= 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:message-id:date:from:mime-version:to:subject :content-type:content-transfer-encoding; s=default; bh=txUR4XnHw CWVtGDWKsLt7EaXB4M=; b=hLZz4ys7j+c1mXWHA7iP27DBlmESK2/d/2ly2b1Iu k7AA4u8zF2/qKwFXjEpBNAXXxYwoxBtq40TePEUt65Gnt7z4D3PZZ4Rz33RmtQGv 57hkjOVLvNurqR3qNYy26OIMc0JjSrpVoN+xH/aoHxwSXNcK1m2b69iXBmt2+nfi cY= Received: (qmail 11348 invoked by alias); 17 Mar 2014 16:00:19 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-gdb=patchwork.siddhesh.in@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 11334 invoked by uid 89); 17 Mar 2014 16:00:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Mar 2014 16:00:17 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1WPZxW-00078l-4s from Hui_Zhu@mentor.com for gdb-patches@sourceware.org; Mon, 17 Mar 2014 09:00:14 -0700 Received: from SVR-ORW-FEM-05.mgc.mentorg.com ([147.34.97.43]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Mar 2014 09:00:14 -0700 Received: from localhost.localdomain (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.2.247.3; Mon, 17 Mar 2014 08:58:28 -0700 Message-ID: <53271C09.5000709@mentor.com> Date: Tue, 18 Mar 2014 00:00:09 +0800 From: Hui Zhu <hui_zhu@mentor.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: gdb-patches ml <gdb-patches@sourceware.org> Subject: [PATCH 0/1] Fix internal warning when "gdb -p xxx" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-DH-Original-To: gdb@patchwork.siddhesh.in |
Commit Message
Hui Zhu
March 17, 2014, 4 p.m. UTC
ps -e | grep a.out 28886 pts/12 00:00:00 a.out gdb -p 28886 Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x0000003b0ccbc970 in __nanosleep_nocancel () from /lib64/libc.so.6 ../../binutils-gdb/gdb/cleanups.c:265: internal-warning: restore_my_cleanups has found a stale cleanup A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) The backtrace of this issue: (gdb) bt #0 0x0000003b0cc35c39 in raise () from /lib64/libc.so.6 #1 0x0000003b0cc37348 in abort () from /lib64/libc.so.6 #2 0x00000000006fdd38 in dump_core () at ../../binutils-gdb/gdb/utils.c:589 #3 0x00000000006fe039 in internal_vproblem (problem=0xcbdc90 <internal_warning_problem>, file=0x8b0c10 "s' failed.", line=265, fmt=0x8b0c38 "nutils-gdb/gdb/cleanups.c", ap=0x7fff803e3ed8) at ../../binutils-gdb/gdb/utils.c:748 #4 0x00000000006fe19c in internal_vwarning (file=0x8b0c10 "s' failed.", line=265, fmt=0x8b0c38 "nutils-gdb/gdb/cleanups.c", ap=0x7fff803e3ed8) at ../../binutils-gdb/gdb/utils.c:799 #5 0x00000000006fe246 in internal_warning (file=0x8b0c10 "s' failed.", line=265, string=0x8b0c38 "nutils-gdb/gdb/cleanups.c") at ../../binutils-gdb/gdb/utils.c:809 #6 0x000000000057da3d in restore_my_cleanups (pmy_chain=0xcba518 <cleanup_chain>, chain=0x14ec030) at ../../binutils-gdb/gdb/cleanups.c:265 #7 0x000000000057da67 in restore_cleanups (chain=0x14ec030) at ../../binutils-gdb/gdb/cleanups.c:276 #8 0x00000000005f0dc7 in catcher_pop () at ../../binutils-gdb/gdb/exceptions.c:116 #9 0x00000000005f0e62 in exceptions_state_mc (action=CATCH_ITER) at ../../binutils-gdb/gdb/exceptions.c:142 #10 0x00000000005f0fe6 in exceptions_state_mc (action=CATCH_ITER) at ../../binutils-gdb/gdb/exceptions.c:203 #11 0x00000000005f18ed in catch_command_errors ( command=0x5d5fb8 <attach_command_continuation_free_args+18>, arg=0x7fff803e525b "2914", from_tty=1, mask=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:549 ---Type <return> to continue, or q <return> to quit--- #12 0x00000000005f5ed7 in captured_main (data=0x7fff803e4280) at ../../binutils-gdb/gdb/main.c:968 #13 0x00000000005f180b in catch_errors (func=0x5f501c <VEC_cmdarg_s_safe_push+43>, func_args=0x7fff803e4280, errstring=0x8cf2e4 "/local/bin", mask=RETURN_MASK_ALL) at ../../binutils-gdb/gdb/exceptions.c:522 #14 0x00000000005f6180 in gdb_main (args=0x7fff803e4280) at ../../binutils-gdb/gdb/main.c:1061 #15 0x000000000045d087 in main (argc=3, argv=0x7fff803e4388) at ../../binutils-gdb/gdb/gdb.c:33 This is a new issue. It is introduced by commit https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8bc2fe488957946d2cdccda3ce8d4f39e4003ea0 It removed the discard_cleanups (back_to) inside attach_command. Then restore_my_cleanups will throw a internal_warning. The most of the pid_to_exec_file target_ops method for some platforms will allocate memory for exec_file and add them to cleanup. So I add a null cleanup to attach_command_post_wait to fix this issue. It is tested and and passed regression test in x86_64-linux. Thanks, Hui 2014-03-17 Hui Zhu <hui@codesourcery.com> * infcmd.c (attach_command_post_wait): Add null_cleanup.
Comments
On 03/17/2014 04:00 PM, Hui Zhu wrote: > The most of the pid_to_exec_file target_ops method for some platforms will > allocate memory for exec_file and add them to cleanup. Which platforms?
On 03/17/2014 04:12 PM, Pedro Alves wrote: > On 03/17/2014 04:00 PM, Hui Zhu wrote: > >> The most of the pid_to_exec_file target_ops method for some platforms will >> allocate memory for exec_file and add them to cleanup. > > Which platforms? OK, I see several do that, including linux-nat.c. IMO, that ends up being a silly interface. The current interface is documented as: /* Attempts to find the pathname of the executable file that was run to create a specified process. The process PID must be stopped when this operation is used. If the executable file cannot be determined, NULL is returned. Else, a pointer to a character string containing the pathname is returned. This string should be copied into a buffer by the client if the string will not be immediately used, or if it must persist. */ #define target_pid_to_exec_file(pid) \ (current_target.to_pid_to_exec_file) (¤t_target, pid) The "This string should be copied into a buffer by the client if the string will not be immediately used, or if it must persist." part hints that the implementation is supposed to return a pointer to a static buffer, like e.g., target_pid_to_str, paddress, and friends, etc. Either we make target_pid_to_exec_file return a pointer to a malloc buffer that the caller is responsible for xfree'ing (and adjust the interface comments in target.h) or we make targets indeed return a pointer to a static buffer, as the current method's description hints at. Returning a malloced buffer, and installing a cleanup like that is a silly interface, IMO. Note that GDB used to have more random memory-release cleanups installed like this, but we've removed most, I believe. Although it's really not harmful to install a cleanup that just releases memory later at any random time, OTOH, it potentially makes debugging nasty cleanup issues harder, so we've moved away from doing that, and we now have that warning. Bummer that we don't have a test that caught this. :-(
--- a/gdb/infcmd.c +++ b/gdb/infcmd.c @@ -2337,6 +2337,7 @@ attach_command_post_wait (char *args, in char *exec_file; char *full_exec_path = NULL; struct inferior *inferior; + struct cleanup *back_to = make_cleanup (null_cleanup, NULL); inferior = current_inferior (); inferior->control.stop_soon = NO_STOP_QUIETLY; @@ -2421,6 +2422,12 @@ attach_command_post_wait (char *args, in if (deprecated_attach_hook) deprecated_attach_hook (); } + + /* The pid_to_exec_file target_ops method for some platforms will + allocate memory for exec_file and add them to cleanup. + Release them in here because function attach_command will be call + by function captured_main too. */ + do_cleanups (back_to); } struct attach_command_continuation_args