From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [patch] Forbid run with a core file loaded
Date: Fri, 21 May 2010 15:06:00 -0000 [thread overview]
Message-ID: <201005211606.07281.pedro@codesourcery.com> (raw)
In-Reply-To: <20100521134718.GA17157@host0.dyn.jankratochvil.net>
On Friday 21 May 2010 14:47:19, Jan Kratochvil wrote:
> Hi,
>
> there is already a protection against loading a core file when a program is
> running.
>
> But one still can now run a program when a core file is loaded. Moreover GDB
> then crashes on `quit'.
>
> (gdb) file sleep
> [...]
> (gdb) start
> [...]
> (gdb) core-file core.5841
> A program is being debugged already. Kill it? (y or n) y
> [...]
> Program terminated with signal 11, Segmentation fault.
> [...]
> (gdb) start
> Starting program: /bin/sleep
> ^^^^^^^^^^^^^^^^ !!!
That's sort of expected. From gdb.texinfo:
"There are three classes of targets: processes, core files, and
executable files. @value{GDBN} can work concurrently on up to three
active targets, one in each class. This allows you to (for example)
start a process and inspect its activity without abandoning your work on
a core file."
This doesn't, and I think never has worked 100% correctly, except
maybe on single-threaded targets, on older GDBs.
Nowadays, it's really not expected and supported to have the
core_ops target remain on the target stack simultaneously and
below a process_stratum target (linux-nat.c, in your case).
I don't think it makes that much sense nowadays to have a
distinct core_stratum vs process_stratum. It core_ops was
a process_stratum, pushing linux-nat.c would auto discard
the core, as you can't have two targets of the same stratum
on the stack. The only main use for that stratum
nowadays is for find_core_target, I think.
> [...]
> (gdb) quit
> A debugging session is active.
> Inferior 1 [process 13887] will be killed.
> Quit anyway? (y or n) y
> inferior.c:362: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
>
> gdb/
> 2010-05-21 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> Forbid run with a core file loaded.
> * infcmd.c (run_command_1) <core_bfd>: New.
What about "attach"?
>
> gdb/testsuite/
> 2010-05-21 Jan Kratochvil <jan.kratochvil@redhat.com>
>
> Forbid run with a core file loaded.
> * gdb.base/corefile.exp (load core again, start with core)
> (started with core): New tests.
>
> --- a/gdb/infcmd.c
> +++ b/gdb/infcmd.c
> @@ -483,6 +483,15 @@ run_command_1 (char *args, int from_tty, int tbreak_at_main)
>
> dont_repeat ();
>
> + if (core_bfd)
> + {
> + if (!from_tty
> + || query (_("Core file is already loaded. Unload it? ")))
> + core_file_command (NULL, from_tty);
> + if (core_bfd)
> + error (_("Core file not unloaded."));
> + }
> +
I wish this would query a target property instead of poking
core_bfd directly, but I don't see what. Several targets call
target_preopen to clean up the previous different target, which
does more cleanup than just getting rid of the core target, but
it looks a bit messy to harmonise this. So I'm fine with
going this route.
"is already loaded" sort of implies (to my ears) that you are
trying to load another core. "load a core --- what do yo mean
? I _already_ have one loaded."
Taking from attach_command, how about:
"A core file is being debugged. Unload it? "
Anyway, that's just a suggestion. Ignore that one if you
don't like it.
--
Pedro Alves
next prev parent reply other threads:[~2010-05-21 15:06 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-21 14:47 Jan Kratochvil
2010-05-21 15:02 ` Mark Kettenis
2010-05-21 15:05 ` Joel Brobecker
2010-05-21 15:40 ` Mark Kettenis
2010-05-23 19:38 ` Jan Kratochvil
2010-05-23 21:08 ` Eli Zaretskii
2010-06-06 19:51 ` Jan Kratochvil
2010-06-06 23:08 ` Eli Zaretskii
2010-06-07 11:21 ` Pedro Alves
2010-06-08 2:33 ` Tom Tromey
2010-06-08 11:03 ` Pedro Alves
2010-07-08 17:17 ` Jan Kratochvil
2010-07-08 18:28 ` Eli Zaretskii
2010-07-19 18:02 ` Jan Kratochvil
2010-07-19 18:05 ` Eli Zaretskii
2010-07-19 18:16 ` Jan Kratochvil
2010-07-27 16:00 ` Joel Brobecker
2010-07-19 14:37 ` Pedro Alves
2010-05-23 21:16 ` Pedro Alves
2010-05-21 15:05 ` Pedro Alves
2010-05-21 15:54 ` Mark Kettenis
2010-05-21 16:08 ` Pedro Alves
2010-05-21 15:07 ` Jan Kratochvil
2010-05-21 15:04 ` Joel Brobecker
2010-05-21 15:06 ` Pedro Alves [this message]
2010-05-21 15:15 ` Joel Brobecker
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=201005211606.07281.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).