[RFA]: Fix crashing bug in set follow-fork-mode

[dan at cgsoftware dot com (Daniel Berlin+gnu.gdb.bug)]

Forget it
Reproduced, and fixed.
It's not even a one liner.
The enum command list has to be NULL terminated.
It wasn't, so it screwed us up beyond belief.

Someone please commit this to the branch if it gets approved.
I have no idea how to make a testcase for it.
I knew something screwy was up when "set follow-fork-mode parent" said
"ambiguous command: \"parent\"", and it clearly wasn't ambiguous at
all.

So, i looked, and it had trashed our stack, and thought we had 6
million matches, rather than one.

--Dan

Patch follows:
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.7
diff -c -3 -p -r1.7 infrun.c
*** infrun.c    2000/04/13 10:22:22     1.7
--- infrun.c    2000/04/16 05:11:11
*************** static char *follow_fork_mode_kind_names
*** 442,448 ****
     the "both" option.
     "parent", "child", "both", "ask" };
   */
!   "parent", "child", "ask"};
 
  static char *follow_fork_mode_string = NULL;
 
 
--- 442,448 ----
     the "both" option.
     "parent", "child", "both", "ask" };
   */
!   "parent", "child", "ask", 0};
 
  static char *follow_fork_mode_string = NULL;
                                                    


> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "alphaev56-dec-osf4.0f"...
> Core was generated by `gdb'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/shlib/libm.so...done.
> Reading symbols from /usr/shlib/libc.so...done.
> #0  0x3ff800d78c8 in strncmp () from /usr/shlib/libc.so
> (gdb) where
> #0  0x3ff800d78c8 in strncmp () from /usr/shlib/libc.so
> #1  0x12006d17c in do_setshow_command (arg=0x14024ec95 "parent", from_tty=0, 
>     c=0x14009f5c0) at command.c:1671
> #2  0x120059f58 in execute_command (p=0x14024ec95 "parent", from_tty=0)
>     at top.c:1540
> #3  0x12005a21c in command_loop () at top.c:1648
> #4  0x120058b50 in read_command_file (stream=0x3ffc00803f0) at top.c:779
> #5  0x12005e41c in source_command (args=0x14008e207 "/tmp/caaaarFaa", 
>     from_tty=0) at top.c:3810
> #6  0x120059f2c in execute_command (p=0x14008e214 "a", from_tty=1)
>     at top.c:1546
> #7  0x120068aa8 in command_handler (
>     command=0x14008e200 "source /tmp/caaaarFaa") at event-top.c:515
> #8  0x12006963c in command_line_handler (rl=0x140347600 "āv4@\001")
>     at event-top.c:811
> #9  0x1201a1948 in rl_callback_read_char () at callback.c:122
> #10 0x120067d8c in rl_callback_read_char_wrapper (client_data=0x0)
>     at event-top.c:166
> #11 0x1200688a8 in stdin_event_handler (error=0, client_data=0x0)
>     at event-top.c:422
> #12 0x1200e5040 in handle_file_event (event_file_desc=0) at event-loop.c:742
> #13 0x1200e45a8 in process_event () at event-loop.c:377
> #14 0x1200e460c in gdb_do_one_event (data=0x0) at event-loop.c:414
> #15 0x1200588c4 in catch_errors (func=0x1200e45d0 <gdb_do_one_event>, 
>     args=0x0, errstring=0x140063c18 "", mask=6) at top.c:615
> #16 0x1200e4658 in start_event_loop () at event-loop.c:438
> #17 0x120067f1c in cli_command_loop () at event-top.c:196
> #18 0x120044360 in captured_command_loop (data=0x0) at main.c:104
> #19 0x1200588c4 in catch_errors (func=0x120044320 <captured_command_loop>, 
>     args=0x0, errstring=0x14005fef8 "", mask=6) at top.c:615
> #20 0x1200451c0 in captured_main (data=0x11fffea88) at main.c:749
> #21 0x1200588c4 in catch_errors (func=0x1200443b4 <captured_main>, 
>     args=0x11fffea88, errstring=0x14005ff00 "", mask=6) at top.c:615
> #22 0x12004520c in main (argc=4, argv=0x11fffeac8) at main.c:761
> 
> Doing a bit more debugging on the core:
> 
> (gdb) up
> #1  0x12006d17c in do_setshow_command (arg=0x14024ec95 "parent", from_tty=0, 
>     c=0x14009f5c0) at command.c:1671
> 1671                  if (strncmp (arg, c->enums[i], len) == 0)
> (gdb) print *c
> $1 = {next = 0x1400adca0, name = 0x14001e4a0 "follow-fork-mode", 
>   class = class_deprecated, function = {cfunc = 0x12006a460 <empty_sfunc>, 
>     sfunc = 0x12006a460 <empty_sfunc>}, 
>   doc = 0x14001f050 "Set debugger response to a program call of fork or vfork.\nA fork or vfork creates a new process.  follow-fork-mode can be:\n parent  - the original process is debugged after a fork\n  child   - the new"..., 
>   flags = 0, replacement = 0x0, hook = 0x0, prefixlist = 0x0, 
>   prefixname = 0x0, allow_unknown = 0 '\000', abbrev_flag = 0 '\000', 
>   completer = 0x12008d6fc <make_symbol_completion_list>, type = set_cmd, 
>   var = 0x1400632e8 "", var_type = var_enum, enums = 0x14001df78, 
>   user_commands = 0x0, hookee = 0x0, cmd_pointer = 0x0}
> (gdb) print arg
> $2 = 0x14024ec95 "parent"
> (gdb) print c->enums[0]
> $3 = 0x1400632d0 "parent"
> (gdb) print c->enums[1]
> $4 = 0x1400632d8 "child"
> (gdb) print c->enums[2]
> $5 = 0x1400632e0 "ask"
> (gdb) print c->enums[3]
> $6 = 0x6f6d20226b736122 <Address 0x6f6d20226b736122 out of bounds>
> (gdb) print i
> $7 = 3
> (gdb) print len
> $8 = 6
> 
> For reasons I don't yet understand, the strncmp is not returning 0 when
> i is 0 (i.e. c->enums[0] == "parent") so it's continuing on to try i = 1,
> i = 2, and then i = 3.  I would imagine that's what's causing the segv --
> strncmp is being passed junk as the second argument when i = 3.  Again,
> I'm not sure why it's getting that far. 
> 
> This code is being executed because ddd is setting up a number of settings
> for gdb which it writes to a temp file and then tells gdb to source.  It's
> while gdb sources this file that the problem happens.  The actual ddd resource
> that contains the settings is:
> 
> Ddd*gdbSettings: \
> set confirm off\n\
> set editing on\n\
> set exec-done-display off\n\
> set history expansion off\n\
> set history save on\n\
> set opaque-type-resolution on\n\
> set overload-resolution on\n\
> set pagination on\n\
> set print address on\n\
> set print array on\n\
> set print asm-demangle on\n\
> set print demangle on\n\
> set print null-stop on\n\
> set print object off\n\
> set print pretty on\n\
> set print sevenbit-strings on\n\
> set print static-members on\n\
> set print symbol-filename on\n\
> set print union on\n\
> set print vtbl off\n\
> set procfs-trace on\n\
> set remotebreak off\n\
> set remotecache off\n\
> set symbol-reloading off\n\
> set unwindonsignal on\n\
> set verbose off\n\
> set write off\n\
> set auto-solib-add 1\n\
> set can-use-hw-watchpoints 1\n\
> set debug arch 0\n\
> set debug event 0\n\
> set debug expression 0\n\
> set debug overload 0\n\
> set debug remote 0\n\
> set debug serial 0\n\
> set debug target 0\n\
> set debugvarobj 0\n\
> set stop-on-solib-events 0\n\
> set architecture auto\n\
> set endian auto\n\
> set demangle-style auto\n\
> set language auto\n\
> set follow-fork-mode parent\n\
> set scheduler-locking off\n\
> set check range auto\n\
> set check type auto\n\
> set annotate 1\n\
> set complaints 0\n\
> set download-write-size 0d512\n\
> set gnutarget auto\n\
> set height 0\n\
> set heuristic-fence-post 0\n\
> set history filename /faculty/ndsu/mooney/.gdb_history\n\
> set history size 0d95000\n\
> set input-radix 0d10\n\
> set listsize 0d10\n\
> set os \n\
> set output-radix 0d10\n\
> set print elements 0d200\n\
> set print max-symbolic-offset 0\n\
> set print repeats 0d10\n\
> set procfs-file procfs_trace\n\
> set prompt (gdb) \n\
> set prompt-escape-char 0\n\
> set remote P-packet auto-detected, currently unknown\n\
> set remote X-packet auto-detected, currently unknown\n\
> set remote Z-packet auto-detected, currently unknown\n\
> set remote memory-read-packet-size 0. Packets are limited to 1088 bytes\n\
> set remote memory-write-packet-size 0. Packets are limited to 1088 bytes\n\
> set remoteaddresssize 0d64\n\
> set remotebaud 0d4294967295\n\
> set remotelogbase ascii\n\
> set remotetimeout 0d2\n\
> set remotewritesize Argument required (integer, `fixed\' or `limited\')\n\
> set watchdog 0\n\
> set width 0\n
> 
> In fact, I can even reproduce the problem if I do:
> 
> 07:58pm dogbert mooney$echo 'set follow-fork-mode parent' > junk
> 07:58pm dogbert mooney$gdb
> GNU gdb 20000413
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "alphaev56-dec-osf4.0f".
> (gdb) source junk
> Segmentation fault (core dumped)
> 
> Please let me know if I can provide further info.
> 
> Thanks!
> 
> Tim