This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Forbid run with a core file loaded


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]