From mboxrd@z Thu Jan  1 00:00:00 1970
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: <gdb@sources.redhat.com>
Cc: Don Howard <dhoward@redhat.com>
Subject: Re: [RFA] deleting breakpoints inside of 'commands'
Date: Thu, 13 Sep 2001 01:01:00 -0000
Message-id: <4.2.0.58.20010913094436.00c609e0@ics.u-strasbg.fr>
References: <Pine.LNX.4.33.0109111057120.1364-100000@theotherone> <4.2.0.58.20010912103028.01ff2a80@ics.u-strasbg.fr>
X-SW-Source: 2001-09/msg00110.html

At 10:37 12/09/01 , vous avez écrit:
>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.
Just a remark to say that  I realized that my suggestion
also has troubles:
   If you imagine that
b func1
command 1
p arg1
   command 1
     p arg2
   end
end
This command should normally print arg1 the first time func1 is hit,
and arg2 afterwards.
   But my suggestion above doesn't handle this !
Of course it should be easy to add a check to test if
the bs->commands still is NULL before restoring
the old value, but this will not be enough,
because it would probably fail in case of
b func1
command 1
p arg1
   command 1
   end
end

where the command is reset after the first hit.
   A possible solution is to create a dummy bs->commands
and to check if it has been change.




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