From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27364 invoked by alias); 16 Apr 2003 14:23:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27348 invoked from network); 16 Apr 2003 14:23:24 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Apr 2003 14:23:24 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 195np0-0008Dk-00; Wed, 16 Apr 2003 09:23:34 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 195non-0002UN-00; Wed, 16 Apr 2003 10:23:21 -0400 Date: Wed, 16 Apr 2003 14:23:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/testsuite] test hand function call in commands list Message-ID: <20030416142321.GA7612@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com References: <20030414154048.GC1151@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030414154048.GC1151@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00319.txt.bz2 On Mon, Apr 14, 2003 at 11:40:48AM -0400, Joel Brobecker wrote: > The attached patch to break.exp was written by Klee Dienes and > submitted in the following message: > > http://sources.redhat.com/ml/gdb-patches/2002-10/msg00586.html > > The purpose of the test is to make sure that a problem occuring with > function calls inside a commands list does not cause a SIGSEGV. > > 2003-04-14 J. Brobecker > > From Klee Dienne > * gdb.base/break.exp: Add multiple calls to the inferior in > the user-commands for 'break 79'. Add a check for the calls > to the inferior in the check for the result. Add new test, to > check that user-defined breakpoint commands are called for functions > called by the user (currently fails). > > When I ran the test, I was very surprised to see one FAIL. I am > describing below the symptoms (no time to investigate this today), but I > think the test is worthwhile adding anyway. Ok to apply? No; let's figure out what the new problem is first. After that let's get the test in as quickly as possible so that we know if it breaks again :) > Here is a small description of the problem: > > The test itself inserted a breakpoint in marker2. It then makes a hand > function call to this function. Here is the output from the logs: > > | print marker2(99) > | > | Breakpoint 26, marker2 (a=99) at ./gdb.base/break.c:49 <<<--- > | 49 int marker2 (a) int a; { return (1); } > | The program being debugged stopped while in a function called from GDB. > | When the function (marker2) is done executing, GDB will silently > | stop (instead of continuing to evaluate the expression containing > | the function call). > > Klee's patch then adds a commands list to the breakpoint in maker2: > > | commands 26 > | Type commands for when breakpoint 26 is hit, one per line. > | End with a line saying just "end". > | >silent > | >call (int) printf ("PREFIXbobo\n" + (int) strlen ("PREFIXbobo\n") - 5) > | >end > > And calls marker2 again: > > | print marker2(99) > | The program being debugged stopped while in a function called from GDB. > | When the function (marker2) is done executing, GDB will silently > | stop (instead of continuing to evaluate the expression containing > | the function call). > > The fact that GDB did not print the breakpoint number shows that GDB > started evaluating the commands list. However, we did not get the > output from the printf command, which means that the evaluation stopped > prematurely for some reason. > > I will be happy to have a look at this problem sometime in the future. > But, if somebody else would like to have a look, no problem either. I can reproduce this. It's even simpler; we aren't executing the commands list even if if there's no inferior function call in them. This appears to be specific to commands on a breakpoint hit during an inferior function call. Did this ever work? It looks like the call to error() when we stop in call_function_by_hand drops us out in start_event_loop, but the call to bpstat_do_actions is in command_handler (closer to the innermost end of the call chain, and thus bypassed by the error()). Should we be calling bpstat_do_actions before that error()? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer