Re: [RFA] deleting breakpoints inside of 'commands'

[Pierre Muller <muller@cerbere.u-strasbg.fr>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1648 bytes --]

At 00:37 12/09/01 , vous avez écrit:


>The following patch addresses a core-dump that occurs when a 'commands'
>script deletes the current breakpoint:
>
>(gdb) commands
> >clear
> >step
> >end
>(gdb) break foo
>(gdb) continue
>         .
>         .
>         .
>warning: Invalid control type in command structure.
>Segmentation fault (core dumped)
>
>What happens is the breakpoint (and the associated 'commands' script) is
>deleted when first statement of the script is executed.  GDB runs into a
>core dump when it attempts to execute the remaining (deleted)
>statements.
>
>The patch below detects if the current breakpoint has been deleted and
>terminates execution of the associated 'commands' script and issues a
>warning.

   Wouldn't it seem more logical to
isolate the commands temporarily,
by resetting the commands field to NULL ?

        headcmd = bs->commands;
+     bs->commands = NULL;
+     cmd = headcmd;
        while (cmd != NULL)

   This would allow to execute the whole
command sequences to its end.
   At end of the commands,
the commands field should be restored if
the breakpoint has not been distroyed,
otherwise headcmd should be disposed.

    This seems a much more reasonable action scheme
to me.

    Otherwise the command parser should at least warn
if any commands are given past a
'clear' or 'delete breakpoint-number',
but this will anyhow not be possible if
the 'delete' argument is an expression that is not a simple constant.


Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99