From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13111 invoked by alias); 28 Jul 2009 12:01:52 -0000 Received: (qmail 12647 invoked by uid 22791); 28 Jul 2009 12:01:48 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Jul 2009 12:01:38 +0000 Received: (qmail 18028 invoked from network); 28 Jul 2009 12:01:35 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Jul 2009 12:01:35 -0000 From: Pedro Alves To: Tom Tromey Subject: Re: Multi-exec patches Date: Tue, 28 Jul 2009 14:28:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, "Ulrich Weigand" , Jan Kratochvil References: <200907231631.n6NGV2xR018887@d12av02.megacenter.de.ibm.com> <200907251612.50134.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200907281301.34095.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-07/txt/msg00674.txt.bz2 On Monday 27 July 2009 18:12:45, Tom Tromey wrote: > >>>>> "Pedro" == Pedro Alves 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 (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, 3 process 2649 at 0x7f0082722c4b, 2 process 2648 at 0x7f0082722c4b, 1 process 2647 at 0x7f0082722c4b, (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