Re: Multi-exec patches

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 27 July 2009 18:12:45, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> Tom> ... which is a little odd, since no build was done.
> Tom> And, what's with process 3931 executing /bin/true?
> Tom> Am I not debugging the 'make' process?
> 
> Pedro> Ah, but you're debugging in all-stop mode.  What this means
> Pedro> is that a program exit is a reason to stop everything and report
> Pedro> to the user.  This was /bin/true exiting.  Check "info inferiors",
> Pedro> and you should still see other inferiors there, waiting for you
> Pedro> to tell them to continue execution.
> 
> I didn't see anything else in "info inferiors", but I am not sure I am
> doing it at the right time.

Here's a full session of what I see, minus the "no debugging symbols
found" messages, where is shows all-stop's behaviour regarding
program exits:

>./gdb /usr/bin/make
GNU gdb (GDB) 6.8.50.20090725-cvs
<snip license etc.>
(gdb) set detach-on-fork off
(gdb) set schedule-multiple on
(gdb) run
Starting program: /usr/bin/make
[Thread debugging using libthread_db enabled]
[New process 2043]
[Thread debugging using libthread_db enabled]
process 2043 is executing new program: /bin/bash
process 2043 is executing new program: /usr/bin/make
[Thread debugging using libthread_db enabled]
make[1]: Entering directory `/home/pedro/gdb/sspaces/build/gdb'
[New process 2044]
[Thread debugging using libthread_db enabled]
process 2044 is executing new program: /bin/bash
[New process 2045]
[New process 2046]
process 2046 is executing new program: /usr/bin/make
[Thread debugging using libthread_db enabled]
make[2]: Entering directory `/home/pedro/gdb/sspaces/build/gdb/gnulib'
make  all-am
[New process 2047]
[Thread debugging using libthread_db enabled]
process 2047 is executing new program: /bin/bash
process 2047 is executing new program: /usr/bin/make
[Thread debugging using libthread_db enabled]
make[3]: Entering directory `/home/pedro/gdb/sspaces/build/gdb/gnulib'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/home/pedro/gdb/sspaces/build/gdb/gnulib'

Program exited normally.
(gdb) info inferiors
  Id   Target ID         SSpace Main Program
  5    process 2046      5      /usr/bin/make
  4    process 2045      4      /bin/bash
  3    process 2044      3      /bin/bash
  2    process 2043      2      /usr/bin/make
  1    process 2040      1      /usr/bin/make

No selected inferior/thread.  See `help thread' or `help inferior'.
(gdb) info sspaces
  Id   Main Program
* 6    /usr/bin/make
  5    /usr/bin/make
        Bound inferiors: ID 5 (process 2046)
  4    /bin/bash
        Bound inferiors: ID 4 (process 2045)
  3    /bin/bash
        Bound inferiors: ID 3 (process 2044)
  2    /usr/bin/make
        Bound inferiors: ID 2 (process 2043)
  1    /usr/bin/make
        Bound inferiors: ID 1 (process 2040)
(gdb)   
(gdb) q
A debugging session is active.

        Inferior 5 [process 2046] will be killed.
        Inferior 4 [process 2045] will be killed.
        Inferior 3 [process 2044] will be killed.
        Inferior 2 [process 2043] will be killed.
        Inferior 1 [process 2040] will be killed.

Do you still want to close the debugger? (y or n) y


We could have a way to make GDB not drop to the CLI
when a program exits, and continue debugging the other
inferiors until they hit a breakpoint or any other event.
That's probably what people would want most of the times
in all-stop mode.  I've been thinking that we'd do that by
defaulting to not drop to the cli on program exits (unless
it's the last inferior of course) and implementing
a "catch exit" to catch exits; or, to have a new user knob for
this ("set stop-on-exit" or something), or make it so
that the behaviour is dependant on schedule-multiple (not so
sure on this one).  I didn't propose any of this, because
frankly, I'm not sure the best UI for it, and, most
importantly, this is the behaviour of what we have had with
multi-forks.  E.g., with gdb 6.8:

>gdb ./testsuite/gdb.base/multi-forks
...
(gdb) set detach-on-fork off
(gdb) r
Starting program: /home/pedro/gdb/sspaces/build/gdb/testsuite/gdb.base/multi-forks
2643 ready
2643 done
Program exited normally.
[Switching to process 2650]
(gdb) info forks
* 4 process 2650 at 0x7f0082722c4b, <fork>
  3 process 2649 at 0x7f0082722c4b, <fork>
  2 process 2648 at 0x7f0082722c4b, <fork>
  1 process 2647 at 0x7f0082722c4b, <fork>
(gdb)

As I said before, I'm not aiming at changing the current
default behaviours of all-stop with this patch set, I'm
mostly aiming at adding the backend infrustructure first.

> I made gdb crash while trying it again today:
> 
> (gdb) set non-stop on
> (gdb) set detach-on-fork off 
> (gdb) run 
> Starting program: /usr/bin/make 
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> Can not resume the parent process over vfork in the foreground while 
> holding the child stopped.  Try "set detach-on-fork" or "set schedule-multiple".
> Recursive internal problem.
> Aborted

Can you get me a backtrace, to see what happened here?

> I also got this strange result:
> 
> (gdb) set detach-on-fork off
> (gdb) set schedule-multiple on
> (gdb) set non-stop on
> (gdb) run
> Starting program: /usr/bin/make 
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> [New process 21131]
> Couldn't get registers: No such process.

This usually means that GDB tried to read registers from
an LWP that wasn't stopped.  I'll try to catch this one.
Are those commands above the whole set of commands?  I
assume that you issued "set target-async on" and "set pagination off"
somewhere too?

> (gdb) info inf
>   Id   Target ID         SSpace Main Program      
> * 2    process 21131     2                        
>   1    process 21128     1      /usr/bin/make     

It looks like the error above happened while handling an exec event,
--- we can see there's a new fork process due to the [New process...]
message, and we can assume that it's execing --- and as GDB didn't get
a chance of loading the new process's executable, the symbol space
does not have a main program loaded.

> Pedro> You need to try it with non-stop mode on.  It should work like you
> Pedro> seem to want it to.   See the "bootstrapping" gdb example here:
> Pedro>  http://sourceware.org/ml/gdb-patches/2009-06/msg00388.html
> 
> Ok, this worked much better.  I was able to interrupt a cc1 process
> during make!

Cool!

> 
> I did see this, I don't know if it is intended:
> 
> (gdb) kill
> Kill the program being debugged? (y or n) y
> You can't do that without a process to debug.

This means that target was no longer pushed on the stack...

> After interrupting cc1, I used "quit".  gdb exited, but then the make
> resumed in the background.

We've talked a bit on IRC, and concluded that you missed applying
patch 2/2 of the mini series, which accounts for at least this one and
the one one above, if not more.

> I ran into another crash somehow:
> 
> ../../archer/gdb/thread.c:708: internal-error: finish_thread_state: Assertion `tp' failed.
> 
> I don't know whether I can reproduce this one.  I tried setting a
> pending breakpoint in c_common_init_options and then running make.

If you have a chance to retry, could you please let me know if you
can reproduce this one with patch 2/2 of the mini-series applied ?

Thanks!

-- 
Pedro Alves