Re: [RFA/testsuite] test hand function call in commands list

[Daniel Jacobowitz <drow at mvista dot com>]

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  <brobecker at gnat dot com>
> 
>         From Klee Dienne <kdienes at apple dot com>
>         * 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