[PATCH] Handle absence of DT_DEBUG while debugging ld.so

[PATCH] Handle absence of DT_DEBUG while debugging ld.so

[Luis Machado]

Hi folks,

When trying to debug ld.so, we may find that the DT_DEBUG entry in
the .dynamic section is missing, thus GDB tries to look for the _r_debug
minimal symbol, and eventually finds it. This works OK as long as the
_r_debug minimal symbol is correct and initialized.

In the case where GDB fetches an uninitialized _r_debug minimal symbol
and tries to access its address, we have a memory access error, just
like below:

(gdb) r
Starting program: /foo/lib/ld.so.1
Cannot access memory at address 0x2f648

Thus, we should guard this piece of code against uninitialized addresses
so that GDB can skip this entry and look for another (hopefully) valid
_r_debug symbol.

Tested against HEAD for ppc32/ppc64 with no regressions. OK?

Regards,
Luis

---
2008-07-28  Luis Machado  <luisgpm@br.ibm.com>

	* solib-svr4.c (elf_locate_base): Check if msymbol's
	address is valid.

Index: gdb/solib-svr4.c
===================================================================
--- gdb.orig/solib-svr4.c	2008-07-28 14:35:20.000000000 -0700
+++ gdb/solib-svr4.c	2008-07-28 16:11:42.000000000 -0700
@@ -508,9 +508,14 @@
     return dyn_ptr;
 
   /* This may be a static executable.  Look for the symbol
-     conventionally named _r_debug, as a last resort.  */
+     conventionally named _r_debug, as a last resort and check if
+     the address contained in the minimal symbol is valid before
+     proceeding.  */
   msymbol = lookup_minimal_symbol ("_r_debug", NULL, symfile_objfile);
-  if (msymbol != NULL)
+  if (msymbol != NULL
+      && !target_read_memory (SYMBOL_VALUE_ADDRESS (msymbol),
+			      (gdb_byte *)&dyn_ptr,
+			      TYPE_LENGTH (builtin_type_void_data_ptr)))
     return SYMBOL_VALUE_ADDRESS (msymbol);
 
   /* DT_DEBUG entry not found.  */

Re: [PATCH] Handle absence of DT_DEBUG while debugging ld.so

[Daniel Jacobowitz]

On Mon, Jul 28, 2008 at 08:54:37PM -0300, Luis Machado wrote:
> Hi folks,
> 
> When trying to debug ld.so, we may find that the DT_DEBUG entry in
> the .dynamic section is missing, thus GDB tries to look for the _r_debug
> minimal symbol, and eventually finds it. This works OK as long as the
> _r_debug minimal symbol is correct and initialized.
> 
> In the case where GDB fetches an uninitialized _r_debug minimal symbol
> and tries to access its address, we have a memory access error, just
> like below:
> 
> (gdb) r
> Starting program: /foo/lib/ld.so.1
> Cannot access memory at address 0x2f648
> 
> Thus, we should guard this piece of code against uninitialized addresses
> so that GDB can skip this entry and look for another (hopefully) valid
> _r_debug symbol.

I think this is a PIE-related problem.  It has nothing to do with
uninitialized, because we're just taking the symbol's
address; but the address you've got there looks wrong.  It's as if
ld.so was loaded at 0x0.  How did that happen?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Handle absence of DT_DEBUG while debugging ld.so

[Luis Machado]

On Mon, 2008-07-28 at 22:27 -0400, Daniel Jacobowitz wrote:
> On Mon, Jul 28, 2008 at 08:54:37PM -0300, Luis Machado wrote:
> > Hi folks,
> > 
> > When trying to debug ld.so, we may find that the DT_DEBUG entry in
> > the .dynamic section is missing, thus GDB tries to look for the _r_debug
> > minimal symbol, and eventually finds it. This works OK as long as the
> > _r_debug minimal symbol is correct and initialized.
> > 
> > In the case where GDB fetches an uninitialized _r_debug minimal symbol
> > and tries to access its address, we have a memory access error, just
> > like below:
> > 
> > (gdb) r
> > Starting program: /foo/lib/ld.so.1
> > Cannot access memory at address 0x2f648
> > 
> > Thus, we should guard this piece of code against uninitialized addresses
> > so that GDB can skip this entry and look for another (hopefully) valid
> > _r_debug symbol.
> 
> I think this is a PIE-related problem.  It has nothing to do with
> uninitialized, because we're just taking the symbol's
> address; but the address you've got there looks wrong.  It's as if
> ld.so was loaded at 0x0.  How did that happen?

Yes, this specific address seems broken somehow. This is the first
_r_debug entry GDB gets:

$6 = {ginfo = {name = 0x10a10b70 "_r_debug", value = {ivalue = 194116,
block = 0x2f644, bytes = 0x2f644 <Address 0x2f644 out of bounds>,
      address = 194116, chain = 0x2f644}, language_specific =
{cplus_specific = {demangled_name = 0x0}}, language = language_auto,
    section = 20, bfd_section = 0x109ea688}, info = 0x0, size = 20,
filename = 0x10a09fe0 "rawmemchr.c", type = mst_bss, hash_next = 0x0,
  demangled_hash_next = 0x0}

And this is the next _r_debug minimal symbol entry GDB gets:

$7 = {ginfo = {name = 0x10a10b70 "_r_debug", value = {ivalue =
134411844, block = 0x802f644,
      bytes = 0x802f644 <Address 0x802f644 out of bounds>, address =
134411844, chain = 0x802f644}, language_specific = {cplus_specific = {
        demangled_name = 0x0}}, language = language_auto, section = 20,
bfd_section = 0x109ea688}, info = 0x0, size = 20,
  filename = 0x10a09fe0 "rawmemchr.c", type = mst_bss, hash_next = 0x0,
demangled_hash_next = 0x0}

Now, i see the very same offset there, but now looks like it has been
shifted to a different address (ld's load address probably).

So, that's why i was imagining it wasn't really initialized yet.

Regards,
Luis

Re: [PATCH] Handle absence of DT_DEBUG while debugging ld.so

[Luis Machado]

On Mon, 2008-07-28 at 23:57 -0300, Luis Machado wrote:
> On Mon, 2008-07-28 at 22:27 -0400, Daniel Jacobowitz wrote:
> > On Mon, Jul 28, 2008 at 08:54:37PM -0300, Luis Machado wrote:
> > > Hi folks,
> > > 
> > > When trying to debug ld.so, we may find that the DT_DEBUG entry in
> > > the .dynamic section is missing, thus GDB tries to look for the _r_debug
> > > minimal symbol, and eventually finds it. This works OK as long as the
> > > _r_debug minimal symbol is correct and initialized.
> > > 
> > > In the case where GDB fetches an uninitialized _r_debug minimal symbol
> > > and tries to access its address, we have a memory access error, just
> > > like below:
> > > 
> > > (gdb) r
> > > Starting program: /foo/lib/ld.so.1
> > > Cannot access memory at address 0x2f648
> > > 
> > > Thus, we should guard this piece of code against uninitialized addresses
> > > so that GDB can skip this entry and look for another (hopefully) valid
> > > _r_debug symbol.
> > 
> > I think this is a PIE-related problem.  It has nothing to do with
> > uninitialized, because we're just taking the symbol's
> > address; but the address you've got there looks wrong.  It's as if
> > ld.so was loaded at 0x0.  How did that happen?
> 
> Yes, this specific address seems broken somehow. This is the first
> _r_debug entry GDB gets:
> 
> $6 = {ginfo = {name = 0x10a10b70 "_r_debug", value = {ivalue = 194116,
> block = 0x2f644, bytes = 0x2f644 <Address 0x2f644 out of bounds>,
>       address = 194116, chain = 0x2f644}, language_specific =
> {cplus_specific = {demangled_name = 0x0}}, language = language_auto,
>     section = 20, bfd_section = 0x109ea688}, info = 0x0, size = 20,
> filename = 0x10a09fe0 "rawmemchr.c", type = mst_bss, hash_next = 0x0,
>   demangled_hash_next = 0x0}
> 
> And this is the next _r_debug minimal symbol entry GDB gets:
> 
> $7 = {ginfo = {name = 0x10a10b70 "_r_debug", value = {ivalue =
> 134411844, block = 0x802f644,
>       bytes = 0x802f644 <Address 0x802f644 out of bounds>, address =
> 134411844, chain = 0x802f644}, language_specific = {cplus_specific = {
>         demangled_name = 0x0}}, language = language_auto, section = 20,
> bfd_section = 0x109ea688}, info = 0x0, size = 20,
>   filename = 0x10a09fe0 "rawmemchr.c", type = mst_bss, hash_next = 0x0,
> demangled_hash_next = 0x0}
> 
> Now, i see the very same offset there, but now looks like it has been
> shifted to a different address (ld's load address probably).
> 
> So, that's why i was imagining it wasn't really initialized yet.
> 
> Regards,
> Luis

btw, to reproduce it, just load ld.so into gdb and "run". You should see
the problem.

Luis

Re: [PATCH] Handle absence of DT_DEBUG while debugging ld.so

[Daniel Jacobowitz]

On Mon, Jul 28, 2008 at 11:57:15PM -0300, Luis Machado wrote:
> Yes, this specific address seems broken somehow. This is the first
> _r_debug entry GDB gets:

Looks like the section offsets are not set yet.

> And this is the next _r_debug minimal symbol entry GDB gets:

What do you mean by "next"?  What commands did you use to get this
output?

Also, with GDB 6.8 I can "continue" after this error.  With HEAD:

Continuing.
Cannot execute this command while the selected thread is running.

Hey, Pedro?  Cleanup trouble?

-- 
Daniel Jacobowitz
CodeSourcery

Re: [PATCH] Handle absence of DT_DEBUG while debugging ld.so

[Luis Machado]

On Tue, 2008-07-29 at 08:12 -0400, Daniel Jacobowitz wrote:
> On Mon, Jul 28, 2008 at 11:57:15PM -0300, Luis Machado wrote:
> > Yes, this specific address seems broken somehow. This is the first
> > _r_debug entry GDB gets:
> 
> Looks like the section offsets are not set yet.
> 
> > And this is the next _r_debug minimal symbol entry GDB gets:
> 
> What do you mean by "next"?  What commands did you use to get this
> output?

"Next" as in the entry GDB locates in the next time it calls
elf_locate_base(...), this time solib_create_inferior_hook(...) is in
the code path after post_create_inferior(...):

#0  elf_locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:494
#1  0x00000000100af30c in locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:570
#2  0x00000000100af9a4 in svr4_current_sos () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:760
#3  0x00000000100ad208 in update_solib_list (from_tty=0, target=0x108fd990) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:494
#4  0x00000000100ad630 in solib_add (pattern=0x0, from_tty=0, target=0x108fd990, readsyms=1)
    at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:677
#5  0x00000000100b0058 in enable_break () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:989
#6  0x00000000100b0a94 in svr4_solib_create_inferior_hook () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:1408
#7  0x00000000100adc60 in solib_create_inferior_hook () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:884
#8  0x00000000101973e8 in post_create_inferior (target=0x108fd990, from_tty=0) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/infcmd.c:441

... whereas the first time it was called:

#0  elf_locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:494
#1  0x00000000100af30c in locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:570
#2  0x00000000100af9a4 in svr4_current_sos () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:760
#3  0x00000000100ad208 in update_solib_list (from_tty=0, target=0x108fd990) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:494
#4  0x00000000100ad630 in solib_add (pattern=0x0, from_tty=0, target=0x108fd990, readsyms=1)
    at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:677
#5  0x00000000101973e0 in post_create_inferior (target=0x108fd990, from_tty=0) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/infcmd.c:433


> Also, with GDB 6.8 I can "continue" after this error.  With HEAD:
> 
> Continuing.
> Cannot execute this command while the selected thread is running.
> 
> Hey, Pedro?  Cleanup trouble?

Yes, i discussed this with Pedro yesterday and he's aware of the
problem.

Luis

Re: [PATCH] Handle absence of DT_DEBUG while debugging ld.so

[Luis Machado]

Ping?

On Tue, 2008-07-29 at 09:45 -0300, Luis Machado wrote:
> On Tue, 2008-07-29 at 08:12 -0400, Daniel Jacobowitz wrote:
> > On Mon, Jul 28, 2008 at 11:57:15PM -0300, Luis Machado wrote:
> > > Yes, this specific address seems broken somehow. This is the first
> > > _r_debug entry GDB gets:
> > 
> > Looks like the section offsets are not set yet.
> > 
> > > And this is the next _r_debug minimal symbol entry GDB gets:
> > 
> > What do you mean by "next"?  What commands did you use to get this
> > output?
> 
> "Next" as in the entry GDB locates in the next time it calls
> elf_locate_base(...), this time solib_create_inferior_hook(...) is in
> the code path after post_create_inferior(...):
> 
> #0  elf_locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:494
> #1  0x00000000100af30c in locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:570
> #2  0x00000000100af9a4 in svr4_current_sos () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:760
> #3  0x00000000100ad208 in update_solib_list (from_tty=0, target=0x108fd990) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:494
> #4  0x00000000100ad630 in solib_add (pattern=0x0, from_tty=0, target=0x108fd990, readsyms=1)
>     at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:677
> #5  0x00000000100b0058 in enable_break () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:989
> #6  0x00000000100b0a94 in svr4_solib_create_inferior_hook () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:1408
> #7  0x00000000100adc60 in solib_create_inferior_hook () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:884
> #8  0x00000000101973e8 in post_create_inferior (target=0x108fd990, from_tty=0) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/infcmd.c:441
> 
> ... whereas the first time it was called:
> 
> #0  elf_locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:494
> #1  0x00000000100af30c in locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:570
> #2  0x00000000100af9a4 in svr4_current_sos () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:760
> #3  0x00000000100ad208 in update_solib_list (from_tty=0, target=0x108fd990) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:494
> #4  0x00000000100ad630 in solib_add (pattern=0x0, from_tty=0, target=0x108fd990, readsyms=1)
>     at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:677
> #5  0x00000000101973e0 in post_create_inferior (target=0x108fd990, from_tty=0) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/infcmd.c:433
> 
> 
> > Also, with GDB 6.8 I can "continue" after this error.  With HEAD:
> > 
> > Continuing.
> > Cannot execute this command while the selected thread is running.
> > 
> > Hey, Pedro?  Cleanup trouble?
> 
> Yes, i discussed this with Pedro yesterday and he's aware of the
> problem.
> 
> Luis
> 

Re: [PATCH] Handle absence of DT_DEBUG while debugging ld.so

[Luis Machado]

Ping?

On Tue, 2008-08-12 at 15:12 -0300, Luis Machado wrote:
> Ping?
> 
> On Tue, 2008-07-29 at 09:45 -0300, Luis Machado wrote:
> > On Tue, 2008-07-29 at 08:12 -0400, Daniel Jacobowitz wrote:
> > > On Mon, Jul 28, 2008 at 11:57:15PM -0300, Luis Machado wrote:
> > > > Yes, this specific address seems broken somehow. This is the first
> > > > _r_debug entry GDB gets:
> > > 
> > > Looks like the section offsets are not set yet.
> > > 
> > > > And this is the next _r_debug minimal symbol entry GDB gets:
> > > 
> > > What do you mean by "next"?  What commands did you use to get this
> > > output?
> > 
> > "Next" as in the entry GDB locates in the next time it calls
> > elf_locate_base(...), this time solib_create_inferior_hook(...) is in
> > the code path after post_create_inferior(...):
> > 
> > #0  elf_locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:494
> > #1  0x00000000100af30c in locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:570
> > #2  0x00000000100af9a4 in svr4_current_sos () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:760
> > #3  0x00000000100ad208 in update_solib_list (from_tty=0, target=0x108fd990) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:494
> > #4  0x00000000100ad630 in solib_add (pattern=0x0, from_tty=0, target=0x108fd990, readsyms=1)
> >     at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:677
> > #5  0x00000000100b0058 in enable_break () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:989
> > #6  0x00000000100b0a94 in svr4_solib_create_inferior_hook () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:1408
> > #7  0x00000000100adc60 in solib_create_inferior_hook () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:884
> > #8  0x00000000101973e8 in post_create_inferior (target=0x108fd990, from_tty=0) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/infcmd.c:441
> > 
> > ... whereas the first time it was called:
> > 
> > #0  elf_locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:494
> > #1  0x00000000100af30c in locate_base () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:570
> > #2  0x00000000100af9a4 in svr4_current_sos () at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib-svr4.c:760
> > #3  0x00000000100ad208 in update_solib_list (from_tty=0, target=0x108fd990) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:494
> > #4  0x00000000100ad630 in solib_add (pattern=0x0, from_tty=0, target=0x108fd990, readsyms=1)
> >     at /home/luis/src/gdb/gdb-head/HEAD3/gdb/solib.c:677
> > #5  0x00000000101973e0 in post_create_inferior (target=0x108fd990, from_tty=0) at /home/luis/src/gdb/gdb-head/HEAD3/gdb/infcmd.c:433
> > 
> > 
> > > Also, with GDB 6.8 I can "continue" after this error.  With HEAD:
> > > 
> > > Continuing.
> > > Cannot execute this command while the selected thread is running.
> > > 
> > > Hey, Pedro?  Cleanup trouble?
> > 
> > Yes, i discussed this with Pedro yesterday and he's aware of the
> > problem.
> > 
> > Luis
> > 
> 

Re: [PATCH] Handle absence of DT_DEBUG while debugging ld.so

[Pedro Alves]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

A Tuesday 29 July 2008 13:12:44, Daniel Jacobowitz wrote:
> On Mon, Jul 28, 2008 at 11:57:15PM -0300, Luis Machado wrote:
> > Yes, this specific address seems broken somehow. This is the first
> > _r_debug entry GDB gets:
>
> Looks like the section offsets are not set yet.
>
> > And this is the next _r_debug minimal symbol entry GDB gets:
>
> What do you mean by "next"?  What commands did you use to get this
> output?
>
> Also, with GDB 6.8 I can "continue" after this error.  With HEAD:
>
> Continuing.
> Cannot execute this command while the selected thread is running.
>
> Hey, Pedro?  Cleanup trouble?

Sort of.  When handling internal events we don't adjust the running
state of the thread, only the executing property.  This is so the
user/frontend doesn't see a bunch of not interesting
running/stopped notifications, like say thread hopping, going through
the shell doing execs, etc.

In this case, we were still not finished with create inferior dances,
and were inside a post_create_inferior.  

Note that post_create_inferior requires a !is_executing inferior, on
entry, and, it is allowed (and it does) to internally start/stop the
inferior (solib handlers do this, see *_create_inferior_hook).

If an error is thrown out of the deep bowls of post_create_inferior,
we should just propagate GDB's knowledge of the executing state to
the user/frontend running state.  This restores the old behaviour.

I now get:

 (gdb) r
 Starting program: /lib/ld-2.7.so
 Cannot access memory at address 0x21ec88
 (gdb) info threads
 * 1 process 30943  0x00007ffff7fe2a60 in ?? ()
 (gdb) c
 Continuing.
 Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
 You have invoked `ld.so', the helper program for shared library executables.

 ...

 Program exited with code 0177.

OK?

-- 
Pedro Alves

[-- Attachment #2: fix_running_state.diff --]
[-- Type: text/x-diff, Size: 1852 bytes --]

2008-07-29  Pedro Alves  <pedro@codesourcery.com>

	* infcmd.c (post_create_inferior): Rename to ...
	(post_create_inferior_1): ... this and make static.
	(fix_running_state): New.
	(post_create_inferior): New.

---
 gdb/infcmd.c |   26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

Index: src/gdb/infcmd.c
===================================================================
--- src.orig/gdb/infcmd.c	2008-07-29 13:40:22.000000000 +0100
+++ src/gdb/infcmd.c	2008-07-29 13:44:02.000000000 +0100
@@ -408,8 +408,8 @@ tty_command (char *file, int from_tty)
    means (running, attaching, connecting, et cetera).  The target
    should be stopped.  */
 
-void
-post_create_inferior (struct target_ops *target, int from_tty)
+static void
+post_create_inferior_1 (struct target_ops *target, int from_tty)
 {
   /* Be sure we own the terminal in case write operations are performed.  */ 
   target_terminal_ours ();
@@ -445,6 +445,28 @@ post_create_inferior (struct target_ops 
   observer_notify_inferior_created (target, from_tty);
 }
 
+/* If an error happened, propagate GDB's knowledge of the executing
+   state to the frontend/user running state.  */
+
+static void
+fix_running_state (void *arg)
+{
+  if (is_exited (inferior_ptid))
+    return;
+  set_running (inferior_ptid,
+	       is_executing (inferior_ptid));
+}
+
+/* See post_create_inferior_1 for description.  */
+
+void
+post_create_inferior (struct target_ops *target, int from_tty)
+{
+  struct cleanup *old_chain = make_cleanup (fix_running_state, NULL);
+  post_create_inferior_1 (target, from_tty);
+  discard_cleanups (old_chain);
+}
+
 /* Kill the inferior if already running.  This function is designed
    to be called when we are about to start the execution of the program
    from the beginning.  Ask the user to confirm that he wants to restart