execute_control_command may not remove its cleanups

[Dave Allan <da_gdb at egenera dot com>]

Hello,

I ran into a reproducible segfault in gdb (v.5.3, but the offending code
is still present in the CVS tree I checked out this morning).  I traced
the problemto the execute_control_command function in cli/cli-script.c. 

It appears that execute_control_command doesn't always do or discard the
cleanups it creates before returning, which is not right according to
the gdb internals docs.  According to section 13.1 Cleanups, "Your
function should explicitly do or discard the cleanups it creates. 
Failing to do this leads to non-deterministic behavior..."

The problem is that the call to do_cleanups in execute_control_command
is conditional (cli/cli-script.c at line 430):

if (old_chain)
  do_cleanups (old_chain);

So, if the cleanup_chain was null entering execute_control_command, then
old_chain will be null, and the call to do_cleanups doesn't happen.  

Removing the if statement, thus making the do_cleanups (old_chain)
unconditional eliminates the segfault.  

Unfortunately, the segfault occurred while I was using gdb run under the
"crash" kernel dump analysis tool, and it appears to me that under
normal gdb usage, cleanup_chain is never null going into
execute_control_command.  Thus, do_cleanups is always executed and the
segfault never appears and I don't have a reproducible test case that
works against a vanilla build.  

However, it seems from code inspection and the gdb internals
documentation that the call to do_cleanups ought to be unconditional. 
Does that seem right?  

Dave