From: Hui Zhu <hui_zhu@mentor.com>
To: gdb-patches ml <gdb-patches@sourceware.org>
Subject: [PATCH 0/1] Fix internal warning when "gdb -p xxx"
Date: Mon, 17 Mar 2014 16:00:00 -0000 [thread overview]
Message-ID: <53271C09.5000709@mentor.com> (raw)
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.
--- 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
next reply other threads:[~2014-03-17 16:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-17 16:00 Hui Zhu [this message]
2014-03-17 16:02 ` [PATCH 1/1] Fix memleak of the pid_to_exec_file target_ops method for some platforms Hui Zhu
2014-03-18 7:39 ` Hui Zhu
2014-03-17 16:12 ` [PATCH 0/1] Fix internal warning when "gdb -p xxx" Pedro Alves
2014-03-17 16:57 ` Pedro Alves
2014-03-18 7:38 ` Hui Zhu
2014-03-18 10:14 ` Pedro Alves
2014-03-19 3:58 ` Hui Zhu
2014-03-19 10:16 ` Pedro Alves
2014-03-20 2:58 ` Hui Zhu
2014-03-20 3:27 ` Hui Zhu
2014-03-20 12:56 ` Pedro Alves
2014-03-21 3:14 ` Hui Zhu
2014-03-19 4:03 ` [PATCH 1/1] Fix internal warning when "gdb -p xxx" (test) Hui Zhu
2014-03-19 10:28 ` Pedro Alves
2014-03-20 3:16 ` Hui Zhu
2014-03-20 12:23 ` Pedro Alves
2014-03-21 3:27 ` Hui Zhu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53271C09.5000709@mentor.com \
--to=hui_zhu@mentor.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox