public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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

  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).